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Section  1 


INTRODUCTION 


t 


INTRODUCTION 


This  report  is  the  sixth  in  a  series  that  is  being  published  by  the  KAPSE 
Interface  Teram  (KIT).  The  previous  reports  are  as  follows: 


Vol.  # 

NOSC  Report  # 

Date 

NTIS  Order  # 

I 

TD-209 

4/82 

ADA115  590 

II 

TD-552 

10/82 

AD  A123  136 

III 

TD-552 

10/83 

ADA141  576 

IV 

TD-552 

4/84 

ADA147  648 

V 

TD-552 

8/85 

AD  A160  355 

This  series  of  reports  serves  to  record  the  activities  to  date  and  to  submit  for 
public  review  the  products  that  have  resulted.  The  reports  are  issued  to  cover  approx¬ 
imate  six-month  periods.  The  reports  should  be  viewed  as  snapshots  of  the  progress  of 
the  KIT  and  the  companion  team,  the  KAPSE  Interface  Team  from  Industry  and  Aca¬ 
demia  (KITIA);  everything  ready  for  public  review  is  included.  These  reports  repre¬ 
sent  evolving  ideas,  so  the  contents  should  not  be  taken  as  fixed  or  final. 

MEETINGS 

During  this  reporting  period  (November  1984  through  April  1985)  the  teams 
met  in  January  1985  in  San  Diego,  CA,  and  in  April  1985  in  Washington,  DC. 
However,  due  to  a  gap  in  contractual  support,  there  are  no  minutes  for  those  two 
meetings.  This  report  does  include,  however,  the  minutes  of  one  working  group’s 
activities  (COMPWG)  during  the  January  meeting.  This  report  also  includes  the 
management  plan  for  1985. 

COMMON  APSE  INTERFACE  SET  (CAIS) 

The  delivery  of  the  Proposed  MIL-STD-CAIS  (known  as  CAIS-1)  was  made  on 
time  to  the  Ada  Joint  Program  Office  (AJPO).  CAIS-1  is  a  significant  milestone  in 
the  life  of  the  KIT  and  KITIA,  one  long  awaited.  Only  the  initial  few  pages  of  this 
document  are  included  in  this  report.  The  full  text  can  be  obtained  from  National 
Technical  Information  Service  (NTIS)  by  using  order  number  AD  A157  589. 

This  draft  takes  into  account  all  of  the  comments  received  at  the  two 
additional  public  review  meetings  held  in  August  and  November  of  1984.  The  input 
from  the  participants  is  quite  valuable.  The  feedback  received  from  the  August 
meeting  regarding  the  incorporation  of  security  in  the  CAIS  is  helpful.  I  would  like  to 
take  this  opportunity  to  again  thank  all  those  who  attended. 

This  draft  is  preceded  by  a  cover  letter  from  Dr.  Robert  Mathis,  director  of  the 
AJPO  at  the  time  the  report  was  delivered.  Dr.  Mathis  states,  there  has  been  a  lot  of 
concern  in  the  community,  once  a  standard  is  issued,  the  standard  could  well  be  mis¬ 
applied.  The  intent  is  to  gain  concurrence  regarding  the  policy  of  application  this  let¬ 
ter  proposes.  Tf  sufficient  support  for  such  a  statement  is  acquired  during  the  stan¬ 
dard  review  process,  words  to  the  effect  of  those  in  this  letter  will  be  incorporated 
into  the  final  standard.  Therefore,  feedback  on  this  aspect  is  welcome. 

Competitive  procurement  of  a  contractor  for  CAIS  Version  2  is  proceeding  and 
is  still  scheduled  to  take  place  during  1985. 
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STANDARDS 

Even  though  the  old  Standards  Working  Group  (STANDWG)  was  folded  into 
the  Compliance  Working  Group  (COMPWG),  the  members  continue  to  provide 
reviews  of  standards  that  may  be  of  interest.  Another  such  report  is  included  in  this 
volume. 

I&T  TOOLS 

Products  are  now  emerging  from  the  effort  to  implement  the  APSE  Interactive 
Monitor  (AIM).  The  first  report  included  here  is  one  by  Stewart  French  discussing  “A 
Virtual  Terminal  Specification  and  Rationale.” 

PROTOTYPING 

A  number  of  what  were  previously  background  issues  have  started  to  emerge, 
now  that  the  first  version  of  the  CAIS  has  been  delivered.  One  of  these  issues  is 
prototyping  and  the  role  prototyping  plays  in  verifying  the  ideas  in  the  CAIS. 

Because  a  number  of  groups  are  starting  to  pursue  prototyping  activities,  we  must 
provide  some  guidelines  for  such  prototyping  and  what  the  KIT/K1TIA  could  and 
should  expect  to  receive  from  such  activities.  These  thoughts  and  discussions  led  to 
the  paper  included  here  by  P.  Oberndorf,  “Prototyping  the  Common  APSE  Interface 
Set  (CAIS).”  This  letter  led  to  the  start  of  a  prototyping  effort  by  TRW,  under 
contract  to  NOSC.  This  effort  is  represented  by  briefing  slides  from  the  Januaiy  1985 
meeting.  This  briefing  discussed  a  variety  of  goals  in  developing  a  CAIS  prototype 
and  their  effect  on  some  of  the  design  issues. 

The  April  1985  meeting  also  was  provided  with  a  briefing  about  the  CAIS 
prototype  being  developed  independently  by  MITRE. 

KIT/KITIA  PAPERS 

One  KITIA  paper  in  included  in  this  report.  The  paper  deals  with  some 
questions  regarding  standardization. 

CONCLUSION 

This  Public  Report  is  provided  by  the  KIT  and  KITIA  to  solicit  comments  and 
feedback  from  those  who  do  not  regularly  participate  on  either  of  the  teams. 
Comments  on  this  and  gill  previous  reports  are  encouraged.  They  should  be  addressed 
to 

Duston  Hayward 
Code  411 

Naval  Ocean  Systems  Center 
San  Diego,  CA  92152-5000 

or  sent  via  ARPANET/MILNET  to  HAYWARD@NOSC-TECR.ARPA. 
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Section  2 

TEAM  PROCEEDINGS 


I 


MINUTES 

KITIA 

COMPLIANCE  WORKING  GROUP 
JANUARY  14-18,  1985 
CATAMARAN 
SAN  DIEGO,  CA. 


B.  Abrams  was  elected  chairman. 

The  Compliance  Working  Group  (COMPWG)  is  concerned  with 
establishing  guidelines  for  measuring  compliance  of 

CAIS  Standard  to  CAIS  Requirements  and  Criterion  Document 

CAIS  Implementation  to  CAIS  Standard. 

The  major  areas  to  be  worked  on  between  now  and  the  next 
meeting  are 

1.  Issues  on  the  validation  test  suite  (V.  Castor) 

2.  Guidelines  for  Subsets  of  a  CAIS  (T.  Lindquist,  R. 
Drake) 

3.  Semantics  -  Guidelines  for  specifying  the  semantics  of 
the  CAIS  so  that  it  can  be  measured.  (R.  Freedman,  B. 
Abrams) 

4.  Standards  -  Comparison  of  CAIS  to  other  Standards  (W. 
Loper) 

5.  CAIS  Standard  compliance  with  CAIS  Requirements.  (J. 
Foidl) 

White  papers  will  be  prepared  prior  to  the  next  KIT/KITIA 
meeting.  The  group  chairman  will  present  a  summary  of  the  papers 
at  that  meeting. 

The  following  is  a  summary  of  the  discussion  on  the  above 
issues.  In  validation  the  emphasis  will  be  technical  rather  than 
administrative.  What  is  validated  must  be  decided.  It  could  be 
a  CAIS  on  a  given  host  computer  -  operating  system  combination. 

Evaluation  is  separate  from  validation.  Validation  is 
concerned  with  the  CAIS  implementation  meeting  the  syntax  and 
semantics  of  the  CAIS  standard.  It  is  objective  and  binary. 
Evaluation  is  concerned  with  performance  and  useability.  It  is 
subjective.  Some  members  were  of  the  opinion  that  we  should  not 
consider  evaluation. 

The  question  of  whether  or  not  there  should  be  subsets  was 
discussed.  It  was  decided  to  consider  the  implications  of 
subsets  first  since  this  may  shed  light  on  the  previous  question. 
If  there  are  subsets  they  should  not  be  arbitrary.  Some  ways  of 
defining  subsets  are: 
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1.0  INTRODUCTION 


The  Ada  Programming  Support  Environment  (APSE)  Interoperability  and 
Transportability  ( I &T )  Plan  is  presented  in  this  document.  The  I&T  activities 
necessary  to  achieve  sharing  of  tools  and  data  bases  between  APSEs  are 
described.  Schedules  and  milestones  for  these  activities  are  presented  as 
well  as  a  Work  Breakdown  Structure  (WBS)  for  accomplishing  them. 

These  I&T  activities  are  conducted  by  the  Kernel  APSE  Interface  Team 
(KIT). 

The  major  responsibilities  are: 

a.  APSE  I&T  Management 

b.  APSE  I&T  Analysis 

c.  APSE  I&T  Standards  Development 

d.  APSE  I&T  Tools  Development 

e.  APSE  I&T  Coordination  with  Implementation  Efforts 


1.1  BACKGROUND 


In  1975  the  High  Order  Language  Working  Group  (HOLWG)  was  formed  under  the 
auspices  of  the  U.S.  Department  of  Defense  (DoD)  with  the  goal  of 
establishing  a  single  high  order  language  for  new  DoD  Embedded  Computer 
Systems  (ECS).  The  technical  requirements  for  the  common  language  were 
finalized  in  the  Steelman  report  [1]  of  June  1978.  International  competition 
was  used  to  select  the  new  common  language  design.  In  1979  the  DoD  selected 
the  design  developed  by  Jean  Ichbiah  and  his  colleagues  at  CII-Honeywell  Bull. 
The  language  was  named  Ada  in  honor  of  Augusta  Ada  Byron  (1816-1851),  the 
daughter  of  Lord  Byron  and  the  first  computer  programmer. 

It  was  realized  early  in  the  development  process  that  acceptance  of  a 
common  language  and  the  benefits  derived  from  a  common  language  could  be 
increased  substantially  by  the  development  of  an  integrated  system  of  software 
development  and  maintenance  tools.  The  requirements  for  such  an  Ada 
programming  environment  were  stated  in  the  STONEMAN  document  [2].  The 
STONEMAN  paints  a  broad  picture  of  the  needs  and  identifies  the  relationships 
of  the  parts  of  an  integrated  APSE.  STONEMAN  identifies  the  APSE  as  support 
for  "the  development  and  maintenance  of  Ada  application  software  throughout 
its  life  cycle".  The  APSE  is  to  provide  a  well -coordinated  set  of  tools  with 
uniform  interfaces  to  support  a  programming  project  throughout  its  life  cycle. 
The  Initial  Operational  Capabilities  (IOCs)  are  called  Minimal  Ada  Programming 
Support  Environments  (MAPSEs). 


[1]  Requirements  For  High  Order  Computer  Programming  Languages:  STEELMAN, 
DoD,  June  1978 

[2]  Requirements  for  Ada  Programming  Support  Environments,  STONEMAN,  DoD, 
February  1980 
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The  Army  and  Air  Force  began  separate  developments  of  APSEs.  The  Army 
APSE  has  been  designated  the  ALS  (Ada  Language  System)  and  that  of  the  Air 
Force,  the  AIE  (Ada  Integrated  Environment).  The  Navy  APSE  will  make  maximum 
use  of  those  Army  and  Air  Force  products  that  meet  Navy  requirements  and  will 
require  the  development  of  only  those  additional  components  required  for  Navy 
applications. 

The  Ada  Joint  Program  Office  (AJPO)  was  formed  in  December  1980.  The  AJPO 
coordinates  all  Ada  efforts  within  DoD  to  ensure  their  compatibility  with  the 
requirements  of  other  Services  and  DoD  agencies,  to  avoid  duplicative  efforts, 
and  to  maximize  sharing  of  resources.  The  AJPO  is  the  principal  DoD  agent  for 
development,  support  and  distribution  of  Ada  tools  and  Ada  common  libraries. 


1.2  DEFINITIONS 


INTEROPERABILITY:  Interoperability  is  the  ability  of  APSEs  to  exchange 
data  base  objects  and  their  relationships  in  forms  usable  by  tools  and  user 
programs  without  conversion.  Interoperabil ity  is  measured  in  the  degree  to 
which  this  exchange  can  be  accomplished  without  conversion. 

TRANSPORTABILITY:  Transportability  of  an  APSE  tool  is  the  ability  of  the 
tool  to  be  installed  on  a  different  KAPSE;  the  tool  must  perform  with  the 
same  functionality  in  both  APSEs.  Transportabil ity  is  measured  in  the  degree 
to  which  this  installation  can  be  accomplished  without  reprogramming. 
Portability  and  transferability  are  commonly  used  synonyms. 


1.3  OBJECTIVES 


The  objectives  of  the  APSE  I &T  effort  are: 

1.  To  develop  requirements  for  APSE  I&T. 

STONEMAN  paints  a  broad  picture  of  the  needs  and  relationships  of 
the  parts  of  an  integrated  APSE.  Although  STONEMAN  is  being  used  as 
the  primary  requirements  document  for  APSE  development  efforts,  it 
does  not  provide  sufficient  detail  to  assure  I&T  between  APSEs. 
APSEs  built  to  accomodate  I&T  requirements  will  insure  cost  savings 
in  the  development  of  tools.  The  cost  of  reprogramming  tools  for 
different  APSEs  will  be  significantly  reduced. 

2.  To  develop  guidelines,  conventions  and  standards  to  be  used  to 
achieve  I&T  of  APSEs. 

Guidelines,  conventions,  and  standards  describe  the  means  by 
which  the  requirements  can  be  satisfied.  It  would  be  premature  to 
develop  steadfast  standards  during  the  early  part  of  this  APSE  I&T 
effort.  There  is  little  precedent  for  I&T  between  programming 
support  environments  of  this  anticipated  magnitude  and  thus  little 
guidance  for  the  development  of  these  guidelines,  conventions,  and 
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standards.  The  guidelines,  conventions  and  standards  that  are 
developed  during  this  APSE  1ST  effort  will  evolve  over  a  five  year 
period  from  1982  through  1987.  These  guidelines,  conventions,  and 
standards  will  be  presented  in  public  forums  to  insure  that  they  are 
sound  and  real i Stic . 

3.  To  develop  APSE  I  ST  tools  to  be  integrated  into  both  APSEs. 

This  APSE  1ST  effort  provides  for  the  development  of  tools  to  be 
integrated  into  various  APSEs.  These  tool  development  efforts  will 
help  identify  interfaces  and  surface  interface  problems  associated 
with  1ST  between  different  APSEs.  They  should  also  show  how  closely 
the  guidelines,  conventions  and  standards  developed  by  this  APSE  1ST 
effort  reflect  the  reality  of  the  various  APSE  efforts.  But  the 
tools  developed  by  this  APSE  1ST  effort  will  not  be  limited  to  this 
test  function.  They  will  also  be  well -documented  tools  which  will 
become  useful  additions  to  any  APSE. 

4.  To  monitor  the  AIE  and  ALS  development  efforts  with  respect  to  APSE 
1ST. 

This  APSE  1ST  effort  provides  for  the  monitoring  of  the  AIE  and 
ALS  development  efforts.  The  monitoring  will  result  in 
recommendations  for  resolution  of  differences  between  the  AIE  or  the 
ALS  and  the  evolving  APSE  1ST  conventions  and  standards.  Interface 
areas  which  would  inhibit  1ST  between  the  AIE  and  ALS  will  also  be 
identified. 

5.  To  provide  initiative  and  give  a  focal  point  with  respect  to  APSE 
1ST. 


A  focal  point  is  needed  for  APSE  developers  and  users  with  regard 
to  information  about  1ST.  APSE  1ST  questions  arise  frequently  within 
professional  societies  and  user  groups.  A  forum  is  needed  in  which 
APSE  1ST  questions  can  be  addressed  and  discussed  and  in  which  APSE 
1ST  information  can  be  disseminated  throughout  the  Ada  community. 

The  KIT  and  KITIA  (see  Sections  2.3  and  2.4)  will  provide  focal 
points  for  the  Ada  community.  Public  reports  on  the  results  of  this 
APSE  1ST  effort  will  be  published  every  six  months.  This  is  in 
keeping  with  the  AJPO  philosophy  of  public  exposure  of  all  aspects  of 
the  Ada  program.  The  KIT  and  KITIA  will  also  participate  in  other 
programs  connected  with  APSE  1ST,  including  international  development 
efforts,  whenever  possible. 

6.  To  develop  and  implement  procedures  to  determine  compliance  of  APSE 
developments  with  APSE  1ST  requirements,  guidelines,  conventions  and 
standards. 

Procedures  must  be  established  by  which  the  recommendations  that 
are  developed  by  this  APSE  1ST  effort  will  be  reviewed  and 
implemented  by  the  AJPO.  The  procedures  that  are  to  be  followed 
should  apply  not  only  to  the  AIE  and  ALS  development  efforts,  but 
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also  to  other  APSE  development  efforts.  Work  on  the  determination  of 
compliance  procedures  will  be  pursued  in  cooperation  with  the  AJPO's 
Evaluation  and  Validation  program. 


1.4  DOCUMENT  ORGANIZATION 


Section  1  of  this  document  discusses  the  purpose  and  scope  of  the  IAT 
Plan,  the  objectives  of  the  IAT  effort,  and  the  basic  concepts,  definitions, 
and  objectives. 

Section  2  discusses  the  sponsorship,  the  participating  organizations,  the 
organizational  inter-relationships  and  responsibilities,  and  the  potential 
forums  for  public  involvement. 

The  specific  tasks  to  be  accomplished  in  pursuit  of  IAT  are  covered  in 
Section  3.  These  functions  are  presented  in  a  work  breakdown  structure  for 
the  project  and  a  schedule  of  milestones  and  deliverables. 

Special  needs  in  achieving  IAT  are  discussed  in  Section  4,  and  a  list  of 
references  is  given  in  Section  5. 

Appendix  A  contains  a  glossary  of  terms  and  acronyms  applicable  to  the  IAT 
effort.  Appendix  B  describes  the  elements  of  the  IAT  Work  Breakdown 
Structure. 
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2.0  ORGANIZATION 


Figure  1  shows  the  participants  in  the  APSE  I&T  effort.  The  following 
sections  provide  a  brief  description  of  these  organizations  and  their 
relationships. 


2.1  Ada  JOINT  PROGRAM  OFFICE 


The  KIT  is  an  agent  of  the  Ada  Joint  Program  Office  (AJPO).  The  KIT 
supports  the  AJPO  by  performing  the  activities  outlined  in  this  plan  and  by 
providing  recommendations  and  information  to  the  AJPO.  The  AJPO  makes  final 
decisions  in  the  areas  of  requirements,  policy,  procedures  and  funding. 

The  Software  Technololgy  for  Adaptable  Reliable  Systems  (STARS)  Joint 
Program  Office  (SJPO)  was  formed  after  the  initiation  of  the  KIT  effort.  It 
has  come  to  take  an  increasing  responsibility  for  efforts  involving  software 
engineering  environments  (SEEs).  Since  the  KIT  work  is  closely  related  to 
such  efforts,  it  is  anticipated  that  sponsorship  of  the  KIT  work  will  move 
from  the  AJPO  to  the  SJPO  in  the  future.  In  the  mean  time,  the  STARS  SEE 
projects  and  the  KIT/KITIA  have  some  co-members  and  share  and  review  one 
another's  documents. 


2.2  ARMY,  AIR  FORCE  AND  NAVY 


Currently  the  Army  and  Air  Force  have  begun  separate  developments  of 
APSEs.  In  the  development  of  its  APSE,  the  Navy  plans  to  make  maximum  use  of 
Army /Air  Force  products  that  meet  Navy  requirements.  The  KIT  will  review  of 
all  these  APSE  developments  and  identify  critical  aspects  of  the  designs  where 
conventions  or  standard  interfaces  and  specifications  are  needed  to  insure 
compatibility.  It  will  be  the  role  of  the  KIT  to  interact  with  these  services 
and  their  respective  APSE  contractors  for  information-exchange  and 
consultation.  The  contractor  for  the  Army's  ALS  is  SofTech  Inc.;  the  Air 
Force  contractor  for  the  AIE  is  Intermetrics  Inc..  The  Navy  contractor  has 
not  been  selected  yet.  Representatives  of  both  the  Air  Force  and  Army  APSE 
development  efforts  are  members  of  the  KIT,  and  many  members  of  the  Navy's 
Design  Review  Group  (DRG)  serve  on  the  KIT  as  well. 
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Figure  1.  APSE  I  AT  Participants 
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2.3  KAPSE  INTERFACE  TEAM  (KIT) 


The  objectives  of  the  KIT  are  the  objectives  of  the  APSE  I  AT  effort  (see 
Section  1.3).  The  Navy  is  responsible  for  chairing  the  KIT.  The  membership 
is  composed  of  the  following  DoD  representatives: 


o  Navy  Deputy  to  the  Ada  Joint  Program  Office 
o  Naval  Ocean  Systems  Center  (NOSC) 
o  Naval  Sea  Systems  Command  (NAVSEA/PMS-408) 
o  Naval  Electronics  Systems  Command  (NAVELEX) 
o  Naval  Underwater  Systems  Center  (NUSC) 
o  Naval  Surface  Weapons  Center  (NSWC) 

o  Naval  Avionics  Center  (NAC) 

o  Naval  Air  Development  Center  (NADC) 

o  Naval  Research  Laboratory  (NRL) 

o  Naval  Weapons  Center  (NWC) 

o  Fleet  Combat  Direction  System  Support  Activity 
(FCDSSA)  -  Dam  Neck 

o  Fleet  Combat  Direction  System  Support  Activity 
(FCDSSA)  -  San  Diego 

o  U.S.  Air  Force  -  Rome  Air  Development  Center  (RADC) 

o  U.S.  Air  Force  -  Air  Force  Wright  Aeronautical 

Laboratories  ( AFWAL ) 

o  U.S.  Army  -  Communications  and  Electronics  Command 
o  Johns  Hopkins  University  Applied  Physics  Laboratory 
( JHUAPL) 

o  National  Security  Agency 

o  Canadian  National  Defense  Headquarters 

NOSC  is  the  Navy  laboratory  which  has  assumed  the  responsibility  of  the 
KIT  chairman.  All  other  members  participate  on  a  volunteer  basis,  aided  as 
necessary  by  the  AJPO  with  funding  for  such  things  as  travel  expenses.  New 
members  will  be  added  to  the  KIT  at  the  discretion  of  the  AJPO. 

Because  of  the  potentially  large  membership  of  the  KIT,  a  management 
steering  committee  called  the  KIT  Executive  Committee  (KITEC)  has  been 
established.  It  consists  of  the  AJPO  sponsor  (i.e.,  the  AJPO  Navy  deputy), 
the  KIT  chairman,  the  primary  support  contractor  (see  Section  2.5),  and 
selected  other  KIT  members  as  determined  by  the  sponsor  and  chairman.  The 
KITEC  is  responsible  for  the  planning  and  management  of  the  APSE  IAT  effort, 
including  maintenance  of  this  plan  and  direction  of  activities  in  accordance 
with  its  tasks  and  schedules. 

In  addition,  the  KIT  is  divided  into  various  working  groups  for  the 
purpose  of  small  group  concentration  on  specific  technical  areas  affecting 
IAT.  The  number,  activities,  and  membership  of  such  working  groups  may  change 
as  KIT  needs  change.  Currently,  the  following  working  groups  are  active: 
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o  Common  APSE  Interface  Set  Working  Group  (CAISWG)  -  The  objective  of 
this  working  group  has  been  to  design  the  initial  set  of  KAPSE-level 
interfaces.  They  are  also  responsible  for  fielding  and  answering  the 
comments  submitted  by  reviewers  of  the  designed  set.  Upon  award  of 
the  contract  for  the  subsequent  version  (CAIS  Version  2),  the  CAISWG 
will  have  primary  responsibil ity  for  technical  evaluation  of  the 
contractor's  products. 

o  Requirements  and  Design  Critieria  Working  Group  (RACWG)  -  The 
objective  of  this  working  group  is  to  define  and  refine  the 
requirements  to  which  CAIS  Version  2  is  to  be  designed. 

o  Guidelines  and  Conventions  Working  Group  (GACWG)  -  The  objective  of 
this  working  group  is  to  define  the  various  guidelines  for  writing 
transportable  software,  in  addition  to  the  use  of  the  CAIS. 

o  STONEMAN  Working  Group  (STONEWG)  -  The  objective  of  this  working 
group  is  to  refine  the  current  STONEMAN  document  to  make  it  more 
useful  and  usable  as  a  guiding  document  for  all  KIT  activities. 

o  Compliance  Working  Group  (COMPWG)  -  The  obkective  of  this  working 
group  is  to  consider  the  CAIS  and  other  KIT  products  from  the 
standpoint  of  determination  of  implementation  conformance. 

o  Definitions  Working  Group  (DEFWG)  -  The  objective  of  this  working 
group  is  to  maintain  consistency  in  the  use  of  terms  in  all  KIT 
documents  and  related  activities. 


2.4  KAPSE  INTERFACE  TEAM  FROM  INDUSTRY  AND  ACADEMIA 


The  KITIA  was  formed  to  complement  the  KIT  and  to  generally  contribute  a 
non-DoD  perspective  to  the  I  AT  effort.  The  KITIA  supplements  the  activities 
of  the  KIT.  It  assures  broad  inputs  from  software  experts  and  eventual  users 
of  APSE's.  The  KITIA  interacts  with  the  KIT  as  reviewers,  as  proposers  of 
APSE  I&T  requirements,  guidelines,  conventions  and  standards,  and  as 
consultants  concerning  implementation  implications.  The  team  was  selected 
from  applicants  representing  industry  and  academia.  The  following  are  the 
members  of  the  KITIA: 

Alpha-Omega  Group 

Aerospace  Corporation 

Bell  Laboratories 

Boeing  Aerospace 

Computer  Sciences  Corporation 

Control  Data  Corporation 

Commission  of  the  Europen  Communities 

Ford  Aerospace 

Frey  Federal  Systems 

General  Electric 

General  Telephone  &  Electronics  Laboratories 
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Georgia  Institute  of  Technology 

Grumman  Aerospace 

Hazel  tine 

Honeywel 1 

Hughes  Aircraft 

IABG  (W.  Germany) 

IBM 

Litton 

Lockheed 

McDonnell  Douglas 

Norden 

PRC 

Raytheon 

SDC 

UK  Ada  Consortium 

Virginia  Polytechnic  Institute 


In  addition,  the  following  is  a  special  associate  member  of  the  team: 

Oy  Softplan  Ab  (Finland) 

Membership  on  the  team  belongs  to  a  company  or  university  and  not  to  an 
individual  representing  his/her  organization.  All  participation  is  voluntary, 
and  the  members  selected  have  agreed  to  provide  1/3  of  a  man-year  plus  other 
support  such  as  travel  expenses.  The  membership  of  the  KITIA  will  not  be 
expanded  unless  an  organization  withdraws  or  very  special  circumstances  apply. 
The  AJPO  sponsor  and  KIT  chairman  are  ex-officio  members  of  the  KITIA. 

The  KITIA  elects  a  chairman  and  a  vice-chairman  from  amongst  its 
participants  every  year.  It  is  organized  into  groups  who  in  turn  select  their 
own  chairmen.  The  KITIA  chairman  and  vice-chairman  together  with  the  group 
chairmen  form  the  KITIA  management  committee.  In  addition,  the  KITIA  is 
divided  into  the  same  set  of  working  groups  as  the  KIT  (see  Section  2.3). 

The  KITIA  is  responsible  to  the  AJPO  through  the  KIT  chairman.  Although 
the  KIT  has  ultimate  responsibility  for  the  development  of  all  products 
required  to  meet  the  IAT  objectives,  the  KITIA  participates  directly  in  the 
generation  and  review  of  such  products.  In  addition,  the  KITIA  generates  its 
own  contributing  papers,  products,  initiatives,  and  recommendations  to 
supplement  and  guide  the  basic  KIT  efforts.  This  requires  close  coordination, 
which  is  facilitated  by  ARPANET/MILNET  communication  mechanisms,  parallel 
working  group  structures,  and  joint  team  meetings. 
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2.5  SUPPORT  CONTRACTORS 


Currently  there  are  two  contractors  that  participate  on  the  KIT.  TRW  is 
the  primary  support  contractor,  providing  general  support  and  technical 
initiatives.  Texas  Instruments  is  developing  an  APSE  tool  in  support  of  the 
IAT  objectives  (see  Section  1.3  3).  A  contractor  to  evolve  the  initial  work 
of  the  KIT/KITIA  CAIS  Working  Group  will  be  selected  in  the  spring  of  1985  via 
a  competitive  award  to  expand  the  Common  APSE  Interface  Set  for  submission  as 
a  military  standard. 


2.6  EVALUATION  AND  VALIDATION  (EAV)  TEAM 


In  keeping  with  the  approach  to  Ada  itself,  the  AJPO  intends  to  be  able  to 
validate  conformance  of  implementations  to  the  CAIS.  Criteria  for  such 
validation  testing  of  the  CAIS  is  the  concern  of  the  COMPWG  (see  Section  2.3), 
working  closely  with  the  Air  Force-lead  Evaluation  and  Validation  Team.  The 
Air  Force  Wright  Aeronautical  Laboratories  is  the  lead  organization  of  the 
Evaluation  and  Validation  Team  which  will  develop  the  technology  required  for 
a  central  agent  to  perform  IAT  validation  testing  on  each  APSE.  The  models 
for  a  strong  central  validation  capability  are  the  Ada  Compiler  Validation 
Capability  and  the  Ada  Validation  Organization  (AVO). 


2.7  USER  GROUPS  AND  PROFESSIONAL  SOCIETIES 


It  is  anticipated  that  SIGAda,  the  Ada-JOVIAL  Users  Group  (Ada-JUG),  and 
Ada  Europe  will  provide  valuable  contributions  to  the  APSE  IAT  effort.  The 
KIT  and  KITIA  have  no  formal  relationship  with  these  groups;  however,  the 
KITEC  will  use  some  or  all  of  these  groups  as  regular  forums  for  the 
presentation  of  reports  and  technical  results  and  will  solicit  feedback  from 
their  members. 


2.8  STANDARDS  ORGANIZATIONS 


The  American  National  Standards  Institute  (ANSI)  and  the  International 
Standards  Organization  (ISO)  are  standards  organizations  which  are  already 
involved  in  establishing  the  Ada  programming  language  as  a  broadly  recognized, 
enforceable  standard.  It  is  possible  that  the  results  of  this  IAT  effort  will 
be  submitted  for  such  approval  by  these  organizations  as  well,  to  effect  the 
commonality  of  APSE's  deemed  necessary  to  achieve  DoD’s  life-cycle  objectives. 
The  KIT  initially  will  become  familiar  with  the  organizations'  standardization 
procedures  so  that  future  standardization  actions  can  be  planned  and 
accomplished  with  minimum  difficulty.  This  will  include  the  study  of  existing 
standards  which  may  interact  with  or  guide  the  development  of  APSE  IAT 
standards. 
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2.9  LIAISON  WITH  IMPLEMENTATION  EFFORTS 


A  number  of  APSE  implementation  efforts  have  been  undertaken  by 
organizations  outside  of  the  OoO.  Three  of  these  (the  U.K.  Ada  Consortium, 
the  West  German  IABG  and  U.C.  Irvine)  have  participated  on  the  KITIA.  Others 
include  the  European  Economic  Community,  ROLM  Corporation,  Western  Digital, 
and  Telesoft,  just  to  name  a  few.  The  KIT  will  keep  such  organizations 
informed  of  its  activities  and  will  consider  all  feedback  received  from  them. 

In  addition,  a  number  of  organizations  are  currently  involved,  to  varying 
degrees,  in  implementations  of  the  first  version  of  the  CAIS.  These 
organizations  have  formed  a  CAIS  Implementor's  Group  (CIG)  which  meets  during 
most  of  the  SIGAda  meetings.  Members  of  the  KIT/KITIA  CAISWG  participate  in 
the  CIG  and  provide  liaison  between  the  groups. 
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3.0  APSE  IAT  PLAN 


This  section  shows  the  Work  Breakdown  Structure  (WBS)  for  the  IAT  effort 
as  well  as  the  schedules  and  milestones  for  the  WBS  elements.  Figures  2  thru 
7  provide  an  overview  for  the  WBS  elements. 


3.1  WORK  BREAKDOWN  STRUCTURE 


A  discussion  of  the  major  elements  in  the  WBS  is  presented  below. 
Detailed  task  descriptions  are  contained  in  Appendix  B. 

1000  APSE  Interoperability  A  Transportability  Management 

This  WBS  element  covers  the  general  management  tasks  required  to 

accomplish  the  APSE  IAT  objectives.  It  includes  general  project  and  team 
management,  project  planning,  general  meeting  and  team  support  and 
configuration  management. 

2000  APSE  Interoperability  A  Transportability  Analysis 

This  WBS  element  covers  the  technical  analysis  tasks  required  to 

accomplish  the  APSE  IAT  objectives.  It  includes  resource  reviews, 
requirements  development,  and  performance  of  special  studies. 

3000  APSE  Interoperability  A  Transportability  Standards 

This  WBS  element  describes  the  standardization  tasks  required  to 

accomplish  the  APSE  IAT  objectives.  It  includes  guidelines  and  conventions 
development,  specification  development,  compliance  and  validation  formulation, 
common  APSE  interface  set  analysis,  and  definition  and  support  of  the 
standardization  process. 

4000  APSE  Interoperability  A  Transportability  Tools 

This  WBS  element  describes  the  development  of  APSE  tools  that  support  the 
APSE  IAT  objectives.  It  includes  planning  and  acquisition  of  tools,  tool 
development,  test  and  analysis,  and  maintenance  and  modification  of  developed 
tool s. 

5000  APSE  Coordination  with  Implementation  Efforts 

This  WBS  element  describes  the  tasks  affecting  various  APSE  development 
efforts  required  to  support  the  APSE  IAT  objectives.  It  includes  public 
reviews  of  the  AIE  and  ALS,  development  of  prototypes  of  the  Common  APSE 
Interface  Set,  IAT  analysis  of  AIE  and  ALS,  and  liaison  with  other 
implementations  groups. 
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Figure  2  WBS  Overview 
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Figure  3  WBS  Management  Overview 


MANAGEMENT 

1000 


PLANNING 

1200 


ADMINISTRATIVE 

SUPPORT 

1300 


Management 

Meeting 

Plan 

Support 

1210 

1310 

Funding 

— 

Team 

Allocation 

Support 

1220 

1320 

Strategy 

- 

Publications 

1230 

1330 

I 

REQ/GL/STD 

- 

Correspondence 

1340 

Page  14 


CONFIGURATION 

MANAGEMENT 

1400 


I4T  Plan 
31  January  1985 


Figure 
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Figure  5  WBS  Standards  Overview 
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Figure  6  WBS  Tools  Overview 
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Figure  7  WBS  Implementation  Effort  Overview 
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3.2  MAJOR  APSE  I&T  DELIVERABLES 


This  section  delineates  the  major  deliverables  of  the  APST  I&T  work. 


3.2.1  APSE  I4T  Plan  - 

The  APSE  I AT  Plan  provides  a  detailed  and  organized  approach  to  the 
accomplishment  of  the  APSE  I&T  work.  The  plan  reflects  the  management  and 
technical  approaches  and  the  schedules  for  all  activities.  The  plan  is 
evolutionary  and  is  apdated  annually  to  reflect  changes  in  approach  or 
schedule  and  to  reflect  accomplishments. 


3.2.2  KIT  Public  Reports  - 

The  KIT  Public  Reports  are  published  every  six  months.  Each  one  reflects 
the  work  that  has  been  accomplished  since  the  previous  report,  including 
deliverables,  working  group  reports,  position  papers  and  meeting  minutes. 


3.2.3  Proposed  Military  Standard  Common  APSE  Interface  Set  -  (MIL-STD-CAIS) 

The  proposed  MIL-STD-CAIS  is  the  specification  of  the  interface  set 
designed  by  the  KIT/KITIA.  This  is  the  main  objective  of  the  APSE  I AT  effort. 
This  document  is  accompanied  by  various  supplemental  ones,  such  as  a  Rationale 
and  an  Implementor's  Guidde. 


3.2.4  Requirements  and  Design  Criteria  - 

The  Requirements  and  Design  Criteria  document  is  intended  to  guide  the 
development  of  CAIS  Version  2.  As  a  KIT  deliverable,  it  is  second  only  to  the 
CAIS  itself  in  importance. 


3.2.5  APSE  I AT  Guidelines  and  Conventions  - 

The  guidelines  and  conventions  covers  those  aspects  of  achieving  I&T  which 
are  not  directly  addressed  by  the  CAIS.  They  cover  such  things  as  using  Ada 
to  write  transportable  software  and  the  style  considerations  which  promote 
I&T. 
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3.3  APSE  1ST  SCHEDULE 

The  schedule  for  the  major  APSE  1ST  events  is  given  in  Figure  8. 


Figure  8  Schedule  Summary 
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4.0  PROVISIONS  FOR  SPECIAL  NEEDS 


This  APSE  IAT  Plan  emphasizes  the  development  of  requirements,  conventions 
and  standards.  It  is  unusual  in  that  it  is  written  for  a  programming  language 
support  environment  that  is  in  the  development  state.  At  this  point  in 
development  it  is  essential  for  the  KIT/KIT  I A  to  provide  an  IAT  forum  and  act 
as  a  focal  point  for  the  Ada  community,  APSE  developers  and  the  DoD.  This 
will  provide  broad  input  to  the  KIT  from  which  a  complete,  realistic  set  of 
IAT  requirements,  guidelines,  conventions  and  standards  will  be  developed  that 
respond  to  ongoing  APSE  development  and  long  term  APSE  needs. 

Normally  to  achieve  APSE  IAT  the  APSE  itself  would  be  written  in  Ada. 
However,  STONEMAN  recognizes  that  "in  cases  where  there  is  a  large  current 
investment  in  software  projects,  written  originally  in  other  languages", 
provisions  and  guidelines  must  be  developed  that  account  for  cost  effective 
transitions  to  Ada  environments.  In  the  development  of  APSE  IAT  requirements, 
conventions,  and  standards  the  KIT/KITIA  should  provide  cost  benefit  analysis 
with  respect  to  their  recommendations  and  decisions  concerning  implementation. 

The  STARS  program  has  come  to  life  in  the  last  two  years.  The  need  for 
close  coordination  between  the  APSE  IAT  effort  and  various  STARS  projects  is 
becomming  increasingly  apparent.  This  is  expected  to  culminate  in  the  shift 
of  APSE  IAT  sponsorship  from  the  AJPO  to  the  SJPO  during  the  next  fiscal  year. 
However,  it  is  not  expected  that  this  will  have  any  noticable  effect  on  APSE 
IAT  schedules  or  objectives.  It  just  helps  to  ensure  that  the  work  on  the 
CAIS  and  other  KIT  efforts  will  be  more  closely  related  to  the  accomplishment 
of  STARS  objectives. 
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I  AT  Plan 
31  January  1985 


5.0  REFERENCE  DOCUMENTS 


Reference  documents  applicable  to  the  APSE  I&T  effort  include: 

o  Requirements  For  High  Order  Computer  Programming  Languages: 
STEELMAN,  DoD,  June  1978 

o  Requirements  for  Ada  Programming  Support  Environments,  STONEMAN,  DoD, 
February  1980 

o  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface  Team: 

Public  Report,  Volume  I,  Naval  Ocean  Systems  Center,  Technical 

Document  509,  1  April  1982. 

o  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface  Team: 

Public  Report,  Volume  II,  Naval  Ocean  Systems  Center,  Technical 

Document  552,  28  October  1982. 

o  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface  Team: 

Public  Report,  Volume  III,  Naval  Ocean  Systems  Center,  Technical 
Document  552,  30  June  1983. 

o  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface  Team: 

Public  Report,  Volume  I,  Naval  Ocean  Systems  Center,  Technical 

Document  552,  30  April  1984. 

o  Proposed  Military  Standard  Common  APSE  Interface  Set,  Ada  Joint 
Program  Office,  31  January  1985. 
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APPENDIX  A 


Ada-JUG 

AIE 

AJPO 

ALS 

ANSI 

APSE 

DIANA 

DoD 

ECS 

FCDSSA 

GCS 

HOLWG 

IOC 

ISO 

I4T 

JCL 

JHUAPL 

KAPSE 

KIT 

KITIA 

KITEC 

MAPSE 

MOA 

NAC 

NADC 

NAVELEX 

NAVSEA 

NOSC 

NRL 

NSWC 

NUSC 

NWC 

RFP 

WBS 


GLOSSARY  OF  TERMS 


Ada-JOVIAL  Users  Group 

Ada  Integrated  Environment 

Ada  Joint  Program  Office 

Ada  Language  System 

American  National  Standards  Institute 

Ada  Programming  Support  Environment 

Descriptive  Intermediate  Attributed  Notation  for  Ada 

Department  of  Defense 

Embedded  Computer  System 

Fleet  Combat  Direction  System  Support  Activity 
Guidelines,  Conventions  and  Standards 
High  Order  Language  Working  Group 
Initial  Operational  Capabilities 
International  Standards  Organization 
Interoperability  and  Transportability 
Job  Control  Language 

John  Hopkins  University  Applied  Physics  Laboratory 
Kernel  Ada  Programming  Support  Environment 
KAPSE  Interface  Team 

KAPSE  Interface  Team  from  Industry  and  Academia 

KAPSE  Interface  Team  Executive  Committee 

Minimal  Ada  Programming  Support  Environment 

Memorandum  of  Agreement 

Naval  Avionics  Center 

Naval  Air  Development  Center 

Naval  Electronic  Systems  Command 

Naval  Sea  Systems  Command 

Naval  Ocean  Systems  Center 

Naval  Research  Laboratory 

Naval  Surface  Weapons  Center 

Naval  Underwater  Systems  Center 

Naval  Weapons  Center 

Request  For  Proposal 

Work  Breadkdown  Structure 
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APPENDIX  B 


WORK  BREAKDOWN  SCHEDULE  TASK  DESCRIPTIONS 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1110  WBS  ELEMENT  TITLE:  Team  Management 


PART  OF  WBS  ELEMENT:  1100  -  Project  Management 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  NOSC  Code  423  with  KITIA  Chairman  support 


TASK  DESCRIPTION:  Assemble  original  teams.  Coordinate  the  solicitation  and 
selection  of  new  members.  Organize  team  structure  into  working  groups. 
Coordinate  KIT  and  KITIA  activities  separately  and  together.  Organize  and 
coordinate  all  team  meetings.  Assign  team  and  working  group  tasks  and  see  to 
their  completion.  Plan  and  chair  meetings.  Cooordinate  the  raising  and 
resol ution  of  i ssues. 


NOTES: 
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UBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  2 

REVISION  DATE:  January  1985 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1130  WBS  ELEMENT  TITLE:  Coordination  with  Software 

for  Adaptable  Reliable  Systems  (STARS) 


PART  OF  WBS  ELEMENT:  1100  Project  Management 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  NOSC  Code  423  with  AJPO 


TASK  DESCRIPTION:  Attend  STARS  workshops.  Cooperate  with  STARS  personnel  to 
assure  proper  incorporation  of  KIT/KITIA  work  into  STARS  plans.  Participate  in 
Joint  Service  Software  Engineering  Environment  (JSSEE)  team  meetings  and 
Software  Engineering  Environment  Area  Coordinating  Team  activities. 


NOTES:  It  is  anticipated  that  the  KIT  effort  will  transfer  to  STARS  JPO 
sponsorship  during  fiscal  year  1986. 


Page  3-27 


WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1140  WBS  ELEMENT  TITLE:  Coodination  with 

Standards  Corrcnunity 


PART  OF  WBS  ELEMENT:  1100  Project  Management 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  NOSC  Code  423  with  AJPO  support 


TASK  DESCRIPTION:  Keep  standards  community  apprised  of  team  activities  and 
progress.  Submit  descriptions  and  reports  as  requested.  Locate  and  track 
relevant  standards  activities. 


NOTES: 
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was  element  description 

ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1150  WBS  ELEMENT  TITLE:  Contracts 


PART  OF  WBS  ELEMENT:  1100  Project  Management 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Initiate  contracts  and/or  tasking  necessary  to  achieve 
project  objectives.  At  minimum,  this  includes  contracts  for  tools  and  general 
support.  Monitor  progress  including  reviews  and  examination  of  deliverables. 
Coordinate  the  incorporation  of  results  of  contracts  into  general  KIT/KITIA 
work. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1210  WBS  ELEMENT  TITLE:  Management  Plan 


PART  OF  WBS  ELEMENT:  1200  Planning 


DCLIVERABLES/MILESTONES:  APSE  14T  Management  Plan  April  1983 

January  1984 
January  1985 
January  1986 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Plan  activities  as  necessary  to  complete  the  APSE  I&T 
project.  Document  all  plans  in  the  APSE  I&T  Management  Plan.  Update  this  plan 
once  a  year,  or  more  often  if  radical  changes  occur. 


NOTES:  An  earlier  version  of  this  plan  was  published  as  CDRL  Item  A001  of 
Delivery  Order  #7N45  on  TRW  Contract  N00123-80-D-0242. 
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WBS  ELEMENT  DESCRIPTION  ORIGINAL  OATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1220  WBS  ELEMENT  TITLE:  Funding  Allocation 


PART  OF  WBS  ELEMENT:  1200  Planning 


DELIVERABLES/MILESTONES:  Budget  updates  as  required. 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Establish  budget  for  project  activities.  Secure  funds  as 
required.  Manage  the  distribution  and  expenditure  of  funds  by  NOSC, 
contractors  and  other  agencies.  Update  budget  as  necessary. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1230  WBS  ELEMENT  TITLE:  Strategy 


PART  OF  WBS  ELEMENT:  1200  Planning 


OELIVERABLES/MILESTONES:  APSE  I&T  Implementation  Strategy  May  1983 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Establish,  plan  and  document  the  strategy  to  be  followed  by 
KIT/KITIA  in  pursuit  of  APSE  I&T  objectives.  Reflect  this  strategy  in  all 
plans,  budgets  and  task  assignments. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1310  WBS  ELEMENT  TITLE:  Meeting  Support 


PART  OF  WBS  ELEMENT:  1300  Administrative  Support 


DELIVERABLES/MILESTONES:  All  support  is-  required  quarterly  in  conjunction  with 
regular  KIT/K1TIA  meetings.  Other  support  is  also  required  for  special 
meetings  and  some  working  group  activities. 


RESPONSIBILITY:  Support  Contractor  with  NOSC  Code  423. 


TASK  DESCRIPTION:  Provide  technical  support  required  in  planning,  preparing 
for,  conducting  and  reporting  on  APSE  I&T  meetings.  Support  includes,  but  is 
not  limited  to,  the  provision  of  agendas,  discussion  copies  of  papers,  meeting 

arrangements ,  minutes  and  attendee  lists. 


NOTES: 


WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1985 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1320  WBS  ELEMENT  TITLE:  Team  Support 


PART  OF  WBS  ELEMENT:  1300  Administrative  Support 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  Support  contractor  with  NOSC  Code  423. 


TASK  DESCRIPTION:  Provide  technical  support  required  for  maintenance,  storage, 
updating  and  distribution  of  documents  and  data  of  the  APSE  I&T  project. 

Support  includes,  but  is  not  limited  to,  maintenance  of  address  lists,  document 
control,  working  paper  preparation  and  MIL  NET  directory  administration,  such 
as  for  KIT-INFORMATION  and  various  comment  directories. 


NOTES: 


Page  3-34 


WBS  ELEMENT  DESCRIPTION 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 


ORIGINATOR:  NOSC 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1331  WBS  ELEMENT  TITLE:  Requirements,  Guidelines, 

Conventions  and  Standards 


PART  OF  WBS  ELEMENT:  1330  Publications/1300  Administarative  Support 


DELIVERABLES/MILESTONES:  Requirements  December  1983 

Guidelines/Conventions  June  1985 

Standard  December  1984 

December  1986 


RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Generate  final  versions  of  all  named  documents.  Submit  them 
to  all  appropriate  publication  processes.  Provide  for  their  distribution  to 
the  KIT/KITIA  and  to  the  public  through  NTIS. 


NOTES:  CAIS  Version  1.1  is  available  as  NTIS  report  #A134  825. 


I 

I 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1332  WBS  ELEMENT  TITLE:  Public  Reports 


PART  OF  WBS  ELEMENT:  1330  Publications/1330  Administrative  Support 


DELIVERABLES/MILESTONES:  Public 

Publ ic 
Publ ic 
Publ ic 
Publ ic 
Publ ic 
Public 
Public 


Report  Vol .  Ill 

April 

1983 

Report  Vol .  IV 

April 

1984 

Report  Vol .  V 

October 

1984 

Report  Vol .  VI 

April 

1985 

Report  Vol .  VII 

October 

1985 

Report  Vol .  VIII 

April 

1986 

Report  Vol.  IX 

October 

1986 

Report  Vol .  X 

April 

1987 

RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Generate  publishable  versions  of  all  public  reports.  This 
includes  determination  and  acquisition  of  contents,  reformatting  as  necessary, 
organization,  submission  to  publication  process,  distribution,  notification  of 
report  availability  and  maintenance  of  the  notification  addressee  list.  Public 
distribution  will  be  through  NTIS. 


NOTES:  Volume  I  is  NTIS  #AD  A1155  590 
Volune  II  is  NTIS  #AD  A123  136 
Volume  III  is  NTIS  #AD  A141  576 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1340  WBS  ELEMENT  TITLE:  Correspondence 


PART  OF  WBS  ELEMENT:  1300  Administrative  Support 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Conduct  communications  as  necessary,  particularly  using  the 
MIL  NET.  NOSC  requirements  in  this  element  include  the  provision  of  terminals, 
ports  and  other  required  facilities  in  support  of  NOSC's  other  tasks. 


NOTES: 

I  __ 

I 


I 

I 
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W8S  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  1400  WBS  ELEMENT  TITLE:  Configuration  Management 


PART  OF  WBS  ELEMENT:  1000  APSE  14T  Management 


DELIVERABLES/MILESTONES: 

Configuration  Management  Report  December  1983 

Final  Configuration  Management  Recommendations  January  1987 


RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Plan  for  configuration  management  of  tools  and  other  products 
developed  under  this  project.  Perform  configuration  management  during  the 
proj ect. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION: 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  2110  WBS  ELEMENT  TITLE:  Relevant  Research 


PART  OF  WBS  ELEMENT:  2100  Resouce  Reviews 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Review  literature  and  documentation  applicable  to  I&T 
requi rements ,  guideline,  conventions  and  standards. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION: 

REVISION  DATE: 


WBS  ELEMENT  NR:  2120  WBS  ELEMENT  TITLE:  Existing  Standards 


PART  OF  WBS  ELEMENT:  2100  Resource  Reviews 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Locate  and  examine  relevant  standards.  Use  and/or  incorporate 
relevant  standards  as  found  to  be  appropriate  and  applicable. 


NOTES:  As  an  example  of  this,  the  Operating  System  Command  and  Response  Language 
(OSCRL)  User  Requirements,  Functional  Requirements  and  Design  Criteria  have  been 
used  as  models  for  the  APSE  I$T  Requirements  and  Criteria.  The  OSCRL  documents 

were  developed  by  X3H1. 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 

REVISION  DATE: 


ORIGINAL  DATE:  30  April  1983 
REVISION: 


WBS  ELEMENT  NR:  2210  WBS  ELEMENT  TITLE:  Definitions  and  Categories 


PART  OF  WBS  ELEMENT:  2200  Requirements  Development 


DELIVERABLES/MILESTONES:  KAPSE  Interface  Worksheets  December  1983 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Develop  definitions  of  all  relevant  terms,  particularly 
"interoperability"  and  "transportabil ity" .  Develop  categories  of  interfaces 
and  KAPSE  Interface  Worksheets  describing  each  of  them. 


NOTES:  Completed 
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UBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  2 

REVISION  DATE:  January  1985 


UBS  ELEMENT  NR:  2220  W8S  ELEMENT  TITLE:  Requirements  and  Design 

Cri teria 


PART  OF  UBS  ELEMENT:  2220  Requirements  Development 


DELIVERABLES/MILESTONES:  Draft  Requirements  and  Design  Criteria  April  1984 

Revision  Requirements  and  Design  Criteria  July  1985 
Final  Requirements  and  Design  Criteria  January  1986 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Develop  functional  requirements  and  interface  design  criteria 
for  a  set  of  interfaces  which  will  achieve  APSE  I&T.  Document  and  analyze  these 
requirements  and  criteria.  Analysis  will  be  conducted  through  public  review  as 
well  as  team  review  and  will  determine  completeness,  consistency  and 
feasibil ity. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  2300  WBS  ELEMENT  TITLE:  Special  Studies 


PART  OF  WBS  ELEMENT:  2000  APSE  IAT  Analysis 


DELIVERABLES/MILESTONES:  Workshops  and  reports  as  appropriate 

Configuration  Management  workshop  June  1983 
Configuration  Management  report  October  1983 


RESPONSIBILITY:  Various  participants 


TASK  DESCRIPTION:  Conduct  technical  analyses  and  studies  as  required.  These 
special  studies  may  include  such  topics  as  command  languages,  configuration 
management,  STONEMAN  revision  and  risks  and  cost  benefits  associated  with 
various  level s  of  I&T. 


NOTES: 


WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 

REVISION  DATE: 


ORIGINAL  DATE:  30  April  1983 
REVISION: 


WBS  ELEMENT  NR:  3100  WBS  ELEMENT  TITLE:  Guidelines  and  Conventions 

Development 


PART  OF  WBS  ELEMENT:  3000  APSE  I&T  Standards 


DELIVERABLES/MILESTONES: 


APSE  I&T  Guidelines  and  Conventions  Review  Draft 
APSE  I&T  Guidelines  and  Conventions  Revision 
APSE  I&T  Guidelines  and  Conventions  Final 


April  1984 
October  1985 
January  1987 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Develop  guidelines  and  conventions  for  achieving  I&T.  These 
supplement  and  further  explain  the  standard,  covering  those  ideas  and  approaches 
that  have  not  been  included  in  the  standard  as  yet  but  which  are  believed  to 
contribute  to  the  achievement  of  I&T. 


NOTES: 
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MBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  3200  WBS  ELEMENT  TITLE:  Specification  Development 


PART  OF  WBS  ELEMENT:  3000  APSE  I4T  Standards 


DELIVERABLES/MILESTONES: 

Common  APSE  Interface  Set  Specification  Review 
CAIS  Version  1  (Proposed  MIL-STD) 

CAIS  Version  2  Review  Draft 

CAIS  Version  2  (Proposed  MIL-STD) 

CAIS  Version  2  MIL-STD 


April  1984 
January  1985 
January  1986 
January  1987 
December  1987 


RESPONSIBILITY:  NOSC  Code  423  and  all  participants 


TASK  DESCRIPTION:  Develop  the  set  of  interface  specifications  which  will  be 
recommended  to  the  AJPO  for  standardization.  Review  and  analyze  these  with 
respect  to  conformance  with  the  requiements  and  criteria  and  to  consistency, 
completeness  and  feasibility. 


NOTES: 


I 

I 
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WBS  ELEMENT  DESCRIPTION 


ORIGINAL  DATE:  30  April  1983 


ORIGINATOR:  NOSC 


REVISION:  2 


REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  3310  WBS  ELEMENT  TITLE:  Compliance  Procedures 


PART  OF  WBS  ELEMENT:  3300  Compliance 


DELIVERABLES/MILESTONES:  Draft  Compliance  Procedures 

Revised  Compliance  Procedures 
Final  Compliance  Procedures 


June 

1984 

October 

1985 

January 

1987 

RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Develop  procedures  for  determining  compliance  of  an  APSE 
implementation  with  APSE  I&T  requirements,  guidelines,  conventions  and 
standards.  Apply  these  procedures  experimentally  to  the  l&T  tools  and  the  AIE 
and  ALS.  The  results  of  this  task  will  influence  the  form  the  standard 
specification  will  take.  Coordinate  with  AJPO  Evaluation  and  Validation  (E&V) 
team. 


NOTES:  This  compliance  work  will  be  conducted  in  close  cooperation  with  the  AJPO 
Evaluation  and  Validation  team  and  wil  form  the  basis  of  the  KIT/KITIA's 
recommendations  to  this  team. 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  3320  WBS  ELEMENT  TITLE:  Validation  Recommendations 


PART  OF  WBS  ELEMENT:  3300  Compliance 


DELIVERABLES/MILESTONES:  Validation  Recommendations 

Validation  Recommendations 


December  1985 
January  1987 


RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Review  the  results  of  the  development  and  application  of  the 
Compliance  Procedures  (WBS  3310).  Formulate  recommendations  for  the  AJPO  and 
its  Evaluation  and  Validation  team. 


NOTES: 


I 

I 


Page  3-47 


WBS  ELEMENT 

DESCRIPTION 

1 

ORIGINAL  DATE:  30  April  1983  ■ 

ORIGINATOR: 

NOSC 

REVISION:  2  " 

REVISION  DATE:  January  1985  | 

MBS  ELEMENT  NR:  3410  W8S  ELEMENT  TITLE:  Experimental  Implementation 


PART  OF  WBS  ELEMENT:  3400  Common  APSE  Interfce  Set  Analysis 


DELIVERABLES/MILESTONES:  Implementation  Report  June  1985 

Implementation  Report  June  1986 

Implementation  Report  June  1987 


RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractors 


TASK  DESCRIPTION:  Experimentally  implement  and  exercise  portions  of  the 
proposed  common  APSE  interface  set  in  order  to  investigate  feasibility, 
completeness,  etc.  Report  results  as  feedback  to  be  incorporated  in  final 
conmon  APSE  interface  set  specification. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  3420 


WBS  ELEMENT  TITLE:  Public  Review 


PART  OF  WBS  ELEMENT:  3400  Common  APSE  Interface  Set  Analysis 


DELIVERABLES/MILESTONES:  Review  Version  1 

Review  Version  2 
Review  Version  2 


November  1984 
June  1986 
June  1987 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Present  the  proposed  standard  for  widespread  public  review, 
including  an  open  review  meeting.  Incorporate  feedback  in  final  document. 


NOTES: 


WBS  ELEMENT  description 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  3500  W8S  ELEMENT  TITLE:  Standard! zation  Process 


PART  OF  WBS  ELEMENT:  3000  APSE  I4T  Standards 


DELIVERABLES/MILESTONES:  Initiate  effort  May  1985 

Standardize  CAIS  Version  1  December  1985 
Standardize  CAIS  Version  2  December  1987 


RESPONSIBILITY:  NOSC  Code  423  with  AJPO 


TASK  DESCRIPTION:  Determine  steps  required  to  achieve  standardization  of  the 
proposed  interface  set.  Pursue  standardization. 


NOTES:  This  activity  alone  among  all  these  tasks  may  be  expected  to  continue 


beyond  the  lifetime  of  the  K IT/KIT  I A . 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  4100  WBS  ELEMENT  TITLE:  Plans  and  Acquisition 


PART  OF  WBS  ELEMENT:  4000  APSE  I4T  Tools 


DELIVERABLES/MILESTONES:  Plans 

Acquisition 


July  1982 
October  1983 


RESPONSIBILITY:  NOSC  Code  423 


TASK  DESCRIPTION:  Identify  the  objectives,  criteria  and  requirements  to  be  used 
for  the  selection  of  three  or  more  APSE  tools.  These  tools  will  be  used  to 
further  analyze  interface  requirements.  Initiate  acquisition  of  such  tools. 


I  _ 

I  NOTES:  Completed 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  4200  WBS  ELEMENT  TITLE:  Tool  Development 


PART  OF  WBS  ELEMENT:  4000  APSE  I4T  Tools 


DELIVERABLES/MILESTONES:  CMS  Design 

AIM  Implementation 
AIM  Transport  Experiment 


June  1983 
June  1985 
August  1985 


RESPONSIBILITY:  Selected  Contractors 


TASK  DESCRIPTION:  Design,  develop  and  test  tools  in  a  local  environment. 
Provide  insights  into  interface  issues  as  they  arise  development  and 
integration. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  4300  WBS  ELEMENT  TITLE:  Test  and  Analysis 


PART  OF  WBS  ELEMENT:  4000  APSE  I4T  Tools 


DELIVERABLES/MILESTONES:  Test  Reports  June  1985 


RESPONSIBILITY:  NOSC  Code  423  with  Support  Contractor 


TASK  DESCRIPTION:  Develop  test  applications  and  analyses  for  determining 
performance  of  APSE  I&T  tools  in  the  AIE  and  ALS.  Apply  these  to  tools  as  they 
are  completed. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION  ORIGINAL  DATE:  30  April  1983 

ORIGINATOR:  NOSC  REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  4400  WBS  ELEMENT  TITLE:  Maintenance  and  Modifica¬ 

tions 


PART  OF  WBS  ELEMENT:  4000  APSE  I4T  Tools 


DELIVERABLES/MILESTONES:  As  required 


RESPONSIBILITY:  NOSC  Code  423  and  Contractors 


TASK  DESCRIPTION:  Provide  maintenance  of  APSE  I&T  tools  as  required  after  their 
development.  Modify  tools  in  accordance  with  needs  to  correct  inadequacies  of 
to  respond  to  changing  requiremnts  or  environments. 


NOTES: 


MBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


MBS  ELEMENT  NR:  5100  MBS  ELEMENT  TITLE:  Public  Reviews  of  A1E  and 

ALS 


PART  OF  MBS  ELEMENT:  5000  APSE  I&T  Coordination  with  Implementation  Efforts 


DELIVERABLES/MILESTONES:  Public  Review  Reports  July  1982  (ALS) 

July  1983  ( AIE) 


RESPONSIBILITY:  NOSC  Code  831 


TASK  DESCRIPTION:  Coordinate  the  establishment  and  notification  of  review 
teams.  Determine  docuemnts  or  systems  to  be  reviewed  and  arrange  for  distri¬ 
bution  of  copies  to  members  of  review  teams.  Receive  all  team  review  reports 
and  correlate  into  report  to  AJPO  and  AIE/ ALS  sponsor. 


NOTES:  Completed 
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MBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  2 

REVISION  DATE:  January  1985 


WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 


REVISION  DATE:  January  1985 

WBS  ELEMENT  NR:  5310  WBS  ELEMENT  TITLE:  KIT/KITIA  Coordination 


TASK  DESCRIPTION:  Provide  channels  of  communication  between  KIT/KITIA  members 
and  government  and  contractor  personnel  involved  in  the  A1E  and  ALS  develop¬ 
ments.  Arrange  for  meetings  and  distribution  of  relevant  documents.  Provide 

feedback  to  AIE  and  ALs  developers. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION:  1 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  5320  WBS  ELEMENT  TITLE:  Analysis  And 

Recommendations 


PART  OF  WBS  ELEMENT:  5300  AIE/ALS  IAT  Analysis 


DELIVERABLES/MILESTONES:  ALS  Analysis  Report  May  1984 


RESPONSIBILITY:  Various  participants 


TASK  DESCRIPTION:  Analyze  AIE  and  ALS  interfaces  with  respect  to  I&T.  Provide 
recorrrnendations  for  evaluation  of  each  system  to  meet  the  interface  set  as  it 
is  put  forward  for  standardization. 


NOTES: 
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WBS  ELEMENT  DESCRIPTION 
ORIGINATOR:  NOSC 


ORIGINAL  DATE:  30  April  1983 
REVISION: 

REVISION  DATE:  January  1985 


WBS  ELEMENT  NR:  5400  WBS  ELEMENT  TITLE:  Liaison  with  Other 

Implementations 


PART  OF  WBS  ELEMENT:  5000  APSE  I&T  Coordination  with  Implementation  Efforts 


DELIVERABLES/MILESTONES:  Continuous 


RESPONSIBILITY:  All  participants 


TASK  DESCRIPTION:  Maintain  awareness  of  and  contact  with  groups  who  are  doing 
non-DoD  APSE  implementations.  Solicit  their  inputs  and  provide  information  on 
KIT/KITIA  activities.  Examples  of  such  groups  are  the  UK,  IABG  in  W.  Germany, 
the  EEC,  ROLM  and  UC  Irvine. 


NOTES: 
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RESEARCH  AND 


ENGINEERING 

(R§AT) 


OFFICE  OF  THE  UNDER  SECRETARY  OF  DEFENSE 


WASHINGTON  DC  20301 


31  JANUARY  1985 


Dear  CAIS  Reviewer: 

The  Common  APSE  Interface  Set  (CAIS)  has  been  developed  to 
facilitate  interoperability  and  transportability  between  APSEs. 
Its  development  was  directed  by  a  January  3,  1982  Memorandum  of 
Agreement  between  the  three  Services  and  the  Deputy  Under 
Secretary  of  Defense  for  Research  and  Engineering  (Acquisition 
Management).  In  that  memorandum,  the  Services  agreed  to 
establish  a  set  of  interfaces  upon  which  formal  coordination  as  a 
military  standard  could  begin.  However,  the  CAIS  is  new  and 
there  is  very  little  experience  with  it  as  yet.  Therefore,  its 
establishment  as  a  military  standard  must  be  accompanied  by  a 
clear  statement  of  the  policy  regarding  its  application  to 
projects  and  contracts. 

The  attached  is  a  proposed  policy  statement  regarding 
appropriate  application  of  CAIS  Version  1  once  it  is  approved  as 
a  military  standard.  The  community  at  large  has  expressed  a 
great  deal  of  concern  over  the  potential  for  misapplication  of 
this  interface  set  when  it  becomes  a  military  standard. 

Therefore,  we  are  submitting  this  draft  policy  statement  for  your 
review  in  addition  to  the  MIL-STD-CAIS  document  itself.  It  is 
requested  that  you  use  the  same  comment  procedures  for  returning 
feedback  on  this  draft  policy  statement  as  for  the  CAIS  document 
itself. 


Robert  F.  Mathis 
Director 

STARS  Joint  Program  Office 


Attachment 
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PROPOSED  CAIS  POLICIES 


1.  Objective:  The  objective  behind  the  creation  of  the  Common 
APSE  Interface  Set  (CAIS)  is  to  promote  the  portability  of 
tools  and  data  between  APSEs.  The  CAIS  has  been  formulated 
to  provide  those  interfaces  most  commonly  required  by  tools 
in  the  course  of  their  normal  operations.  When  the  CAIS  has 
matured  to  the  point  of  wide  acceptance  by  industry,  the  DoD 
will  move  to  apply  this  standard  to  the  DoD-funded 
environments. 

2.  Purpose:  This  set  of  interfaces  is  being  issued  as  a 
military  standard  in  order  to  allow  its  application  to 
government  contracts.  The  principal  purpose  of  such 
application  is  to  allow  contracts  to  specify  the  use  of  the 
CAIS  in  experimental  implementations  whose  objective  is  to 
learn  about  the  viability,  feasibility,  implementability  and 
usability  of  the  interface  set  as  a  component  of  a 
programming  support  environment.  Implementations  of  this 
proposed  interface  set  should  provide  knowledge  about 
implementation  of  its  features  and  feedback  to  the  CAIS 
designers  relevant  to  the  development  of  Version  2  of  the 
CAIS. 

3.  Proper  Uses:  Proper  applications  of  this  standard  to 
contracts  include:  (1)  prototype  implementations  of  the 
interface  set,  either  wholly  or  in  part;  (2)  prototype 
implementations  of  tools  written  to  run  on  top  of  a  CAIS 
implementation;  (3)  implementation/comparison  studies 
designed  for  such  purposes  as  determining  the  probable  ease 
of  implementing  the  CAIS  on  a  new  operating  system  or  bare 
machine  or  comparing  the  features  available  in  the  CAIS  with 
those  considered  essential  in  another  operating  system;  and 
(4)  experimental  studies  designed  to  utilize  a  prototype 
CAIS  and/or  tool  implementation  in  order  to  gather 
information  regarding  performance,  usability,  viability, 

etc . 

4.  Improper  Uses:  It  is  not  intended  that  the  CAIS  Version  1 
military  standard  be  imposed  on  any  development  or 
maintenance  project  whose  primary  purpose  is  not  explicitly 
to  experiment  with  its  implementation  or  that  would  be 
unnecessarily  risking  total  project  success  on  the 
(unproven)  viability  of  the  current  CAIS.  The  CAIS  should 
not  be  imposed  nonchalantly  or  arbitrarily  or  without  a 
clear  understanding  of  the  potential  costs  and  risks 
involved. 

5.  Feedback:  All  uses  made  of  the  CAIS  should  require  at  least 
one  report  intended  to  provide  feedback  to  the  CAIS 
designers  regarding  the  pros  and  cons  of  its  implementation 
and  use,  ease  or  difficulty  encountered  with  particular 
features,  and  suggestions  for  improvements  to  either  the 
form  or  technical  content  of  the  military  standard  document. 
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NOTE:  This  draft,  dated  31  January  1985,  prepared 
by  the  KAPSE  Interface  Team  and  KAPSE  Interface 
Team  from  Industry  and  Academia  CAIS  Working 
Group  for  the  Ada*  Joint  Program  Office,  has  not 
been  approved  and  is  subject  to  modification. 

DO  NOT  USE  PRIOR  TO  APPROVAL. 

(Project  IPSC/ECRS  0208) 


PROPOSED 
MIL-STD-CAJS 
31  JANUARY  1985 


MILITARY  STANDARD 
COMMON  APSE  INTERFACE  SET 

(CAIS) 


AREA  ECRS 


*Ada  is  a  Registered  Trademark  o’  the  U  S. Government.  (Ada  Joint  Program  Office) 
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PROPOSED  MIL-sTD-r  Ai 
31  JANl  ARY  in« 


DEPARTMENT  of  DEFENSE 
Washington,  DC  20302 


Common  APSE  Interface  Set 

MIL-STD- 

1.  This  Military  Standard  is  approved  for  use  by  all  Departments  and  Agencies  of  the 
Department  of  Defense. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  which 
may  be  of  use  in  Improving  this  document  should  be  addressed  to  KIT/K1TIA  CAJS 
Working  Group  and  sent  to  Patricia  Oberndorf,  Naval  Ocean  Systems  Center,  Code  423, 
San  Diego,  CA,  92152-5000  by  using  the  self  addressed  Standardization  Document 
Improvement  Proposal  (DD  Form  1428)  appearing  at  the  end  of  this  document  or  by  letter. 
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PROPOSED  MI!/-sTD-<  \IS 
.11  JAMARV  1085 


FOREWORD 

This  document  has  been  prepared  in  response  to  the  Memorandum  of  Agreement  signed  by  the 
Undersecretary  of  Defense  and  the  Assistant  Secretaries  of  the  Air  Force,  Army,  and  Navy.  The 
memorandum  established  agreement  for  defining  a  set  of  common  Interfaces  for  the  Department  of 
Defense  (DoD)  Ada  Programming  Support  Environment  (APSEs)  to  promote  Ada  tool  transportability 
and  interoperability.  The  initial  interfaces  for  the  CAJS  were  derived  from  the  Ada  Integrated 
Environment  (AIE)  and  the  Ada  Language  System  (ALS).  Since  then  the  CAJS  has  been  expanded  to 
be  implementable  as  part  of  a  wide  variety  of  APSEs.  It  is  anticipated  that  the  CAIS  will  evolve  to 
meet  new  needs.  Through  the  acceptance  of  ■  ,s  standard,  it  is  anticipated  that  the  source  level 
portability  of  Ada  software  tools  will  be  enhanced  for  both  DoD  and  non-DoD  users. 

The  authors  of  this  document  include  technical  representatives  from  the  two  DoD  APSE  contractors, 
representatives  from  the  DoD’s  Kernel  Ada  Programming  Support  Environment  (KAPSE)  Interface 
Team  (KIT),  and  volunteer  representatives  from  the  KAPSE  Interface  Team  from  Industry  and 
Academia  (KITIA). 

The  initial  effort  for  definition  of  the  CAJS  was  begun  In  September  1982  by  the  following  members  of 
the  KAPSE  Interface  Team  (KIT):  J.  Foidl  (TRW),  J.  Kramer  (Institute  for  Defense  Analyses), 
P.  Oberndorf  (Naval  Ocean  Systems  Center),  T.  Taft  (Intermetrics),  R.  Thall  (SofTech)  and 
W.  Wilder  (NAVSEA  PMS-408).  In  February  1983  the  design  team  was  expanded  to  include  LCDR 
B.  Schaar  (Ada  Joint  Program  Office),  T. Harrison  (Texas  Instruments)  and  KAPSE  Interface  Team 
from  Industry  and  Academia  (KITIA)  members:  H.  Fischer  (Litton  Data  Systems),  E.  Lamb  (Boll 
Labs),  T.  Lyons  (Software  Sciences  Ltd.,  U.K.).  D.  McGonagle  (General  Electric),  II.  Morse  (Frey 
Federal  Systems),  E.  Ploedereder  (Tartan  Laboratories),  H.  Willman  (Raytheon),  and  L.  Yelowitz 
(Ford  Aerospace).  During  1984,  the  following  people  assisted  in  preparation  of  this  document.  F.  Belz 
(TRW)  and  the  TRW  prototype  team,  K.  Connolly  (TRW),  S.  Ferdman  (Data  General),  G.  Fitch 
(Intermetrics),  R.  Gouw  (TRW),  B.  Grant  (Intermetrics),  N.  Lee  (Institute  for  Defense  Analyses), 
J.  Long  (TRW),  and  R.  Robinson  (Institute  for  Defense  Analyses).  Additional  constructive  criticism 
and  direction  was  provided  by  G.  Myers  (Naval  Ocean  Systems  Center),  O.  Roublne  (Informatique 
Internationale),  and  the  general  memberships  of  the  KIT  and  KITIA,  as  well  as  many  Independent 
reviewers.  The  Ada  Joint  Program  Office  is  particularly  grateful  to  these  KITIA  members  and  their 
companies  for  providing  the  time  and  resources  that  significantly  contributed  to  this  document. 

This  document  was  prepared  with  the  Uniloglc  Ltd.  SCRIBE  typeset  tool  on  the  TRW  Software 
Productivity  Project  development  environment. 
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1.  SCOPE 


1.1.  Purpose 

This  document  provides  specifications  for  a  set  of  Ada  packages,  with  their  Intended  semantics,  which 
together  form  the  set  of  common  interfaces  for  Ada  Programming  Support  Environments  (APSEs). 
This  set  of  interfaces  is  known  as  the  Common  APSE  Interface  Set  (CAIS).  This  interface  set  is 
designed  to  promote  the  source-level  portability  of  Ada  programs,  particularly  Ada  software 
development  tools. 

The  CAIS  applies  to  Ada  Programming  Support  Environments  which  are  to  become  the  basic- 
software  life-cycle  environments  for  Department  of  Defense  (DoD)  mission  critical  computer  systems 
(MCCS).  Those  Ada  programs  that  are  used  in  support  of  software  development  are  defined  as  tools. 
This  includes  the  spectrum  of  support  software  from  project  management  through  code  development, 
configuration  management  and  life-cycle  support.  Tools  are  not  restricted  to  only  those  software 
items  normally  associated  with  program  generation,  such  as  editors,  compilers,  debuggers,  and  linker- 
loaders.  Groups  of  tools  that  are  composed  of  a  number  of  independent  but  interrelated  programs 
(such  as  a  debugger  which  is  related  to  a  specific  compiler)  are  classed  as  tool  sets1  . 

Since  the  goal  of  the  CAIS  Is  to  promote  it  leroperability  and  transportability  of  Ada  software  across 
DoD  APSEs,  the  following  definitions  of  these  terms  are  provided. 

Interoperability  Is  defined  as  the  ability  of  APSEs  to  exchange  data  base  objects  and  their 
relationships  in  forms  usable  by  tools  and  user  programs  without  conversion.  Transportability  of 
an  APSE  tool  is  defined  as  the  ability  of  the  tool  to  be  installed  on  a  different  KAPSE;  the  tool 
must  perform  with  the  same  functionality  In  both  APSEs.  Transportability  is  measured  in  the 
degree  to  which  this  installation  can  be  accomplished  without  reprogramming.  Portability  and 
transferability  are  commonly  used  synonyms.2 

The  CAIS  is  intended  to  evolve  as  APSEs  are  implemented,  as  tools  are  transported,  and  as  tool 
interoperability  issues  are  encountered.  Tools  written  in  Ada.  using  only  the  packages  described 
herein,  should  be  transportable  between  CAIS  Implementations.  Where  tools  function  as  a  set,  the 
CAIS  facilitates  transportability  of  the  tool  set  as  a  whole;  tools  might  not  be  individually 
transportable  becau  e  they  depend  on  inputs  from  other  tools  In  the  set. 


1.2.  Content 

The  CAIS  establishes  interface  requirements  for  the  transportability  of  Ada  tool  sets  to  be  used  in 
Department  of  Defense  (DoD)  APSEs.  Strict  adherence  to  this  Interlace  set  will  ensure  that  Ada  tool 
sets  will  possess  the  highest  degree  of  transportability  across  conforming  APSEs. 

The  scope  of  the  CAIS  includes  interfaces  to  those  services,  traditionally  provided  by  an  operating 
system,  that  affect  tool  transportability.  Ideally,  all  APSE  tools  would  be  implcmcntable  using  only 
the  Ada  language  and  the  CAIS.  The  CAJS  is  intended  to  provide  the  transportability  interfaces 
most  often  required  by  common  software  development  tools  and  includes  four  interface  areas: 

a.  Node  Model.  This  area  presents  a  model  for  the  CAIS  In  which  contents,  relationships  and 
attributes  of  nodes  are  defined.  Also  included  are  the  foundations  for  access  control  and 
access  synchronization. 
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b.  Processes.  This  area  covers  program  invocation  and  control. 

c.  input  and  Output.  This  area  covers  Hie  Input  and  output,  basic  device  input  and  output 
support,  special  device  control  facilities,  and  Interprocess  communication. 

d.  Utilities.  This  area  covers  list  operations  useful  for  manipulation  of  parameters  and 
attribute  values. 


1.3.  Excluded  and  deferred  topics 

During  the  design  of  the  CAJS  it  was  determined  that  Interfaces  for  environments  which  are  not 
software  development  environments  (for  example,  interfaces  on  target  systems)  and  interfaces  for 
multilingual  environments  should  be  explicitly  excluded.  It  has  been  decided  that  backup  facilities 
will  be  supported  transparently  by  the  CAIS  implementation.  While  the  interface  issues  of  most 
aspects  of  environments  were  considered,  the  complete  resolution  of  several  areas  has  been  deferred 
until  later  revisions  of  the  CAIS.  These  areas  are: 

a.  Configuration  management.  The  current  CAIS  supports  facilities  for  configuration  control 
including  keeping  versions,  referencing  the  latest  revision,  identifying  the  state  of  an 
object,  etc.;  but  It  does  not  implement  a  particular  methodology.  Currently  deferred  is  the 
decision  whether  or  not  the  CAIS  should  enforce  a  particular  configuration  management 
approach  and.  If  so,  what  particular  methodology  should  be  chosen. 

b.  Device  control  and  resource  management.  The  current  CAJS  provides  control  facilities  for 
scroll,  page  and  form  terminals  and  magnetic  tape  drives.  Currently  deferred  is  the 
decision  as  to  what  additional  devices  or  resources  must  be  supported  by  the  CAJS.  Such 
resources  and  devices  might  include  printers,  disk  drives,  color  terminals,  vector-  and  bit- 
addressable  graphics  devices,  processor  memory,  processor  time,  communication  paths,  etc. 

Also  deferred  Is  a  decision  regarding  which  other  American  National  Standards  Institute  or 
International  Standards  Organization  interfaces  to  adopt,  such  as  the  ISO/DIS  75M2 
Graphical  Kernel  System  (GKS). 

c.  Distributed  environments.  The  existing  CAJS  packages  are  intended  to  be  implcmentable 
on  a  distributed  set  of  processors,  but  in  a  manner  that  is  transparent  to  a  tool.  Currently 
deferred  Is  the  deck  ion  whether  or  not  to  provide  to  the  user  explicit  CAJS  Interfaces  to 
control  the  distribution  of  the  environment,  including  de-ignatlon  of  where  nodes  exist  and 
where  execution  takes  place.  Note  that  a  set  of  distributed  processors  could  include  one  or 
more  target  machines. 

d.  Inter-tool  interfaces.  The  current  CAIS  docs  not  define  inler-looi  calling  sequences  or  data 
formats  such  as  the  data  format  within  the  compilation/program  library  system,  the  text 
format  within  editing  systems,  the  command  processor  language  syntax,  the  message 
formats  of  a  mail  system,  or  the  Interaction  between  the  run-time  system  and  debugger 
tools.  Currently  deferred  are  decisions  regarding  what  Inter-tool  data  should  become  part 
of  the  standard,  what  form  such  Interfaces  should  take,  and  whether  or  not  to  place 
constraints  on  the  run-time  system  to  provide  process  execution  information. 

e.  Interoperability.  The  current  CAIS  provides  only  a  very  primitive,  text-oriented  Interface 
for  transferring  files  between  a  CAIS  implementation  and  the  operating  system  on  which  it 
may  reside.  It  does  not  define  external  representations  of  data  for  transfer  between 
environments  or  between  a  host  and  target. 

f.  Typing  methodology.  The  current  CAIS  provides  attributes  and  relations  which  can  be 
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used  by  tool  sots  to  constrain  nodes,  attributes,  and  relations,  but  it  does  not  enforce  a 
particular  methodology.  Currently  deferred  is  a  decision  whether  or  not  the  CAIS  should 
enforce  a  particular,  more  complete  typing  methodology  and  what  kind  of  CAIS  interfaces 
should  be  made  available  to  support  it. 

g.  Archiving.  The  current  CAJS  does  not  define  facilities  for  archiving  data.  Currently 
deferred  Is  a  decision  regarding  the  form  that  archiving  interfaces  should  take. 
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2.  REFERENCED  DOCUMENTS 

2.1.  Issues  of  documents 

The  following  documents  of  the  issue  In  effect  on  date  of  invitation  for  bids  or  request  for  proposal 
form  a  part  of  this  standard  to  the  extent  specified  herein. 

[LRM]:  Reference  Manual  for  the  Ada  Programming  Language.  ANSl/MII.rSTD-18l5A;  United  Stales 
Department  of  Defense;  January  1983. 

(Copies  of  specifications,  standards,  drawings,  and  publications  required  by  contractors  in  connection 
with  specific  procurement  functions  should  be  obtained  from  the  procuring  activity  or  as  directed  by 
the  contracting  officer.) 

2.2.  Other  publications 

The  following  documents  form  a  part  of  the  standard  to  the  extent  specified  herein.  Unless  otherwise 
indicated,  the  issue  in  effect  on  date  of  Invitation  for  bids  or  request  for  proposal  shall  apply. 

[ANSI  78):  American  National  Standards  Institute,  Magnetic  Tape  Labels  and  File  Structure  for 
Information  Interchange  (ANSI  Standard  xS.27-1978).  (Application  for  copies  should  be  addressed 
to  American  National  Standards  Institute,  Inc.,  1430  Broadway.  New  York,  NY  10018) 

[DACS]:  DACS  Glossary,  a  Bibliography  of  Software  Engineering  Terms.  GLOS-1,  October  1979,  Data 
and  Analysis  Center  for  Software.  (Application  for  copies  should  be  addressed  to  Data  and  Analysis 
Center  Tor  Software,  RADC/IS1SI,  Grimss  AFB,  NY  13441) 

[IEEE]:  IEEE  Standard  Glossary  of  Software  Engineering  Terminology,  ANSI/IEEE  Std.  729-1983. 
(Application  for  copies  should  be  addressed  to  Sales  Department,  American  National  Standards 
Institute,  1430  Broadway,  New  York,  NY  10018) 

[STONEMAJV]:  Requirements  for  Ada  Programming  Support  Environments,  STONEMAN; 

Department  of  Defense;  February  1980. 

(TCSEC|:  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria,  Department  of 
Defense  Computer  Security  Center,  CSC-STD-001-83,  15  August  1983.  (Application  for  copies  should 
be  addressed  to  Department  of  Defense,  Computer  Security  Center,  Office  of  Standards  and  Products, 
Attention:  Chief,  Computer  Security  Standards,  Fort  George  G.  Meade,  Maryland  20755.) 

[UK  Ada  Study]:  United  Kingdom  Ada  Study  Final  Technical  Report,  Volume  I,  London,  Department 
of  Industry,  1981.  (Application  for  copies  should  be  addressed  to  Scientific  Information  Office,  British 
Defence  Staff,  British  Embassy,  3100  Massachusetts  Avenue,  NW,  Washington,  D.C.  20008.) 

[WEBS]:  Webster's  New  Collegiate  Dictionary,  G.&C.  Merriam  Company,  Springfield.  Massachusetts. 
1979. 
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3.  DEFINITIONS 

The  following  is  an  alphabetical  listing  of  terms  which  are  used  in  the  description  of  the  CAJS.  Where 
a  document  named  in  Section  2  was  used  to  obtain  the  definition,  the  definition  is  preceded  by  a 
bracketed  reference  to  that  document. 

abort  -  [IEEE]  To  terminate  a  process  prior  to  completion. 

access  -  [TCSEC]  A  specific  type  of  interaction  between  a  subject  and  an  object  that  results  in  the 
flow  of  information  from  one  to  the  other. 

access  checking  -  The  operation  of  checking  access  rights  against  those  rights  required  for  the 
intended  operation,  according  to  the  access  control  rules,  and  either  permitting  or  denying  the 
intended  operation. 

access  control  -  [TCSEC]  (I)  discretionary  access  control:  A  means  of  restricting  access  to  objects 
based  on  the  identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls  are  discretionary 
in  the  sense  that  a  subject  with  a  certain  access  permission  Is  capable  of  passing  that  permission 
(perhaps  indirectly)  on  to  any  other  subject.  (2)  mandatory  access  control:  A  means  of  restricting 
access  to  objects  based  on  the  sensitivity  (as  represented  by  a  label)  of  the  Information  contained  in 
the  objects  and  the  formal  authorization  (l.e.,  clearance)  of  subjects  to  access  Information  of  such 
sensitivity.  In  the  CAIS,  this  includes  specification  of  access  rights,  access  control  rules  and  checking 
of  access  rights  in  accordance  with  these  rules. 

access  control  constraints  -  The  resulting  restrictions  placed  on  certain  kinds  or  operations  by 
access  control. 

access  control  information  -  All  the  information  required  to  perform  across  checking. 

access  control  rules  -  The  rules  describing  the  correlations  between  access  rights  and  those  rights 
required  for  an  intended  operation. 

access  relationship  -  A  relationship  of  the  predefined  relation  ACCESS, 
access  rights  -  Descriptions  of  the  kinds  of  operations  which  can  be  performed. 

access  to  a  node  -  Reading  or  writing  of  the  contents  of  the  node,  reading  or  writing  of  attributes  of 
the  node,  reading  or  writing  of  relationships  emanating  from  a  node  or  of  their  attributes,  and 
traversing  a  node  as  Implied  by  a  pathname. 

accessible  -  The  subject  has  (adopted  a  role  which  has)  been  granted  the  access  right  EXISTENCE 
to  the  object. 

active  position  -  The  position  at  which  a  terminal  operation  is  to  be  performed. 

Ada  Programming  Support  Environment  (APSE)  -  (UK  Ada  Study,  STONEMAN]  A  set  of 
hardware  and  software  facilities  whose  purpose  is  to  support  the  development  and  maintenance  of 
Ada  applications  software  throughout  its  life-cycle  with  particular  emphasis  on  software  for  embedded 
computer  applications.  The  principal  features  are  the  database,  the  Interfaces  and  the  tool  set. 

adopt  a  role  -  The  action  of  a  process  to  acquire  the  access  rights  which  have  boon  or  will  tie 
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granted  by  an  object  to  adopters  of  that  role;  In  the  CAIS  this  is  accomplished  by  establishing  a 
secondary  relationship  of  the  predefined  relation  ADOPTED _  ROLE  from  the  process  node  to  the 
node  representing  the  role. 

adopted  role  of  a  process  -  The  access  rights  associated  with  the  node  that  is  the  target  of  a 
relationship  of  the  predefined  relation  ADOPTED  _  ROLE  emanating  from  the  process  node  or  with 
any  group  node  one  of  whose  permanent  members  Is  the  target  of  such  a  relationship. 

advance  (of  an  active  position)  -  (l)  Scroll  or  page  terminal:  Occurs  whenever  (I)  the  row  number  of  a 
new  position  Is  greater  than  the  row  number  of  the  old  or  (II)  the  row  number  of  the  new  position  Is 
the  same  and  the  column  number  of  the  new  position  is  greater  than  that  of  the  old.  (2)  Form 
terminal:  Occurs  whenever  the  indices  of  its  position  are  incremented. 

approved  access  rights  -  Access  rights  whose  names  appear  in  resulting  rights  lists  of  relevant 
grant  items  for  which  either  (i)  the  necessary  right  is  null  or  (II)  the  necessary  right  is  an  approved 
access  right. 

area  qualifier  -  A  designator  for  the  beginning  of  a  qualified  area. 

attribute  -  A  named  value  associated  with  a  node  or  relationship  which  provides  Information  about 
that  node  or  relationship. 

closed  node  handle  -  A  node  handle  which  is  not  associated  with  any  node, 
contents  -  A  file  or  process  associated  with  a  CAIS  node. 

couple  -  To  establish  a  correlation  between  a  queue  file  and  a  secondary  storage  rile.  If  the  queue  file 
Is  a  copy  queue  file,  its  initial  contents  is  a  copy  of  the  secondary  storage  file  to  which  It  Is  coupled;  if 
the  queue  file  is  a  mimic  queue  file,  its  Initial  contents  is  a  copy  of  the  secondary  storage  file  to  which 
It  is  coupled,  and  elements  that  are  written  to  the  mimic  queue  file  are  appended  to  its  coupled  file. 

current  job  -  The  root  process  node  of  the  tree  containing  the  current  process  node;  represented  by 
the  predefined  relation  CURRENT_JOB. 

current  node  -  The  node  that  Is  currently  th  *  focus  or  context  for  the  activities  of  the  current 
process;  represented  by  the  predefined  relation  CURRENT_  NODE. 

current  process  -  The  currently  executing  process  making  the  call  to  a  CAIS  operation.  Pathnames 
are  interpreted  in  the  context  of  the  current  process. 

current  user  -  The  user’s  top-level  node;  represented  by  the  secondary  relationship  of  the  predefined 
relation  CURRENT _  USER. 

dependent  process  -  A  process  other  than  a  root  process. 

device  [WEBS]  -  A  piece  of  equipment  or  a  mechanism  designed  to  serve  a  special  purpose  or  perform 
a  special  function. 

device  name  -  The  keys  of  a  primary  relationship  of  the  predefined  relation  DEVICE. 

discretionary  access  control  -  See  access  control. 
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element  (of  a  file)  -  A  value  of  the  generie  (lata  type  with  which  the  input  and  output  package  was 
instantiated;  see  [l,RM)  for  additional  information. 

end  position  -  The  position  of  a  form  identified  by  the  highest  row  and  column  indices  of  the  form. 

external  file  -  [LRM  14.1.1  -  Ada  external  file]  Values  input  from  the  external  environment  of  the 
program,  or  output  to  the  environment,  are  considered  to  occupy  external  files.  An  external  file  can 
be  anything  external  to  the  program  that  can  produce  a  value  to  be  read  or  receive  a  value  to  be 
written. 

file  -  See  external  file. 

file  handle  -  An  object  of  type  FILE_TYPE  which  Is  used  to  identify  an  internal  file. 

file  node  -  A  node  whose  contents  are  an  Ada  external  file,  e.g.,  a  host  system  file,  a  device,  or  a 
queue. 

form  -  A  form  is  a  two-dimensional  matrix  of  character  positions. 

group  -  A  collection  of  nodes  representing  roles  and  identified  by  a  structural  node  with  emanating 
relationships  of  the  predefined  relations  POTENTIAL _  MEMBER  and  PERMANENT  _  MEMBER 
identifying  each  of  the  group's  members.  A  member  may  be  a  user  top-level  node,  a  node 
representing  the  executable  image  of  a  program,  or  a  node  representing  a  group. 

illegal  identification  -  A  node  Identification  in  which  the  pathname  or  the  relationship  key  or 
relation  name  is  syntactically  illegal  with  respect  to  the  syntax  defined  In  Table  I. 

inaccessible  -  The  subject  has  not  (adopted  a  role  which  has)  been  granted  the  access  right  or 
EXISTENCE  to  the  object. 

initiate  -  To  place  a  program  into  execution;  in  the  CAJS,  this  means  a  process  node  is  created,  a 
process  is  created  as  its  contents,  required  resources  are  allocated,  and  execution  Is  started. 

initiated  process  -  The  process  whose  program  has  been  placed  Into  execution. 

initiating  process  -  The  process  placing  a  program  Into  execution. 

interface  -  (DACS)  A  shared  boundary. 

internal  file  -  A  file  which  is  internal  to  a  CAJS  process.  Such  a  file  is  identified  by  a  file  handle. 

iterator  -  A  variable  which  provides  the  bookkeeping  information  necessary  for  iteration  over  nodes 
(a  node  iterator)  or  attributes  (an  attribute  iterator). 

job  -  A  process  node  tree,  spanned  by  primary  relationships,  which  develops  under  a  root  process 
node  as  other  (dependent)  processes  are  initiated  for  the  user. 

key  -  See  relatic. r  hip  key.  The  key  of  a  node  Is  the  relationship  key  of  the  last  element  of  the 
node's  pathname. 

label  group  (of  a  magnetic  tape)  -  One  of  the  following:  (I)  a  volume  header  and  a  file  header  label. 
(II)  a  file  header  label,  or  (iii)  an  end-of-flle  label. 
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latest  key  -  The  final  part  of  a  key  that  Is  automatically  assigned  lexicographically  following  ail 
previous  keys  for  the  same  relation  names  and  initial  relationship  key  character  sequence  for  a  given 
node. 

list-  [IEEE]  An  ordered  set  of  items  of  data;  in  the  CA1S,  an  entity  of  type  LIST _ TYPE  whose  value 
is  a  linearly  ordered  set  of  data  elements. 

list  item  -  A  data  element  in  a  list. 

mandatory  access  control  -  See  access  control. 

named  item  -  a  list  Item  which  has  name  associated  with  it. 

named  list  -  a  list  whose  items  are  all  named. 

node  -  A  representation  within  the  CAIS  of  an  entity  relevant  to  the  APSE. 

node  handle  -  An  Ada  object  of  type  NODE_TYPE  which  is  used  to  identify  a  CAIS  node:  it  is 
internal  to  a  process. 

non-existing  node  -  A  node  which  has  never  been  created. 

object  -  [TCSEC]  A  passive  entity  that  contains  or  receives  information.  In  the  CAJS.  any  node  may 
be  an  object. 

obtainable  -  A  node  Is  obtainable  if  It  is  created  and  not  deleted. 

open  node  handle  -  A  node  handle  that  has  been  assigned  to  a  particular  node. 

parent  -  The  source  node  of  a  primary  relationship;  also  the  target  or  a  relationship  of  the  predefined 
relation  PARENT. 

path  -  A  sequence  of  relationships  connecting  one  node  to  another.  Starting  from  a  given  node,  a 
path  is  followed  by  traversing  a  sequence  of  relationships  until  the  desired  node  is  reached. 

path  element  -  A  portion  of  a  pathname  representing  the  traversal  of  a  single  relationship;  a  single 
relation  name  and  relationship  key  pair. 

pathname  -  A  name  for  a  path  consisting  or  the  concatenation  of  the  names  of  the  traversed 
relationships  in  the  path  in  the  same  order  in  which  they  are  traversed. 

permanent  member  -  A  group  member  which  is  Intrinsically  related  to  the  group  via  primary 
relationships  of  the  predefined  relation  PERMANENT _  MEMBER. 

position  (of  a  terminal)  -  A  place  In  an  output  device  In  which  a  single,  printable  ASCII  character 
may  be  graphically  disputed. 

potential  member  -  A  group  member  that  may  dynamically  acquire  membership  in  the  group: 
represented  by  a  node  that  Is  the  target  of  a  secondary  relationship  of  the  predefined  relation 
POTKNTIAL_ MEMBER  emanating  from  that  group  node  or  from  any  of  that  group  nodes' 
descendants. 
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descendant  (of  a  node)  -  Any  node  which  Is  reachable  from  other  nodes  via  primary  relationships. 

pragmatics  -  Constraints  imposed  by  an  implementation  that  are  not  defined  by  the  syntax  or 
semantics  of  the  CAJS. 

primary  relationship  -  The  initial  relationship  established  from  an  existing  node  to  a  newly  created 
node  during  its  creation.  The  existence  of  a  node  is  determined  by  the  existence  of  the  primary 
relationship  of  which  it  is  the  target. 

process  -  The  execution  of  an  Ada  program,  including  all  Its  tasks, 
process  node  -  A  node  whose  contents  represent  a  CAIS  process. 

program  -  [LRM|  A  program  Is  composed  of  a  number  of  compilation  units,  one  of  which  is  a 
subprogram  called  the  main  program. 

qualified  ares  -  A  contiguous  group  of  positions  in  a  form  that  share  a  common  set  of 
characteristics. 

queue  -  [IEEE]  A  list  that  is  accessed  in  a  flrst-ln,  flrst-out  manner, 
relation  -  In  the  node  model,  a  class  of  relationships  sharing  the  same  name, 
relation  name  -  The  string  that  identifies  a  relation. 

relationship  -  In  the  node  model,  an  edge  of  the  directed  graph  which  emanates  from  a  source'  node 
and  terminates  at  a  target  node.  A  relationship  is  an  instance  of  a  relation. 

relationship  key  -  The  string  that  distinguishes  a  relationship  from  other  relationships  having  the 
same  relation  name  and  emanating  from  the  same  node. 

relevant  grant  items  -  The  items  In  values  of  GRANT  attributes  of  relationships  of  the  relation 
ACCESS  emanating  from  the  object  and  pointing  at  any  node  representing  a  role  which  is  an  adopted 
role  of  the  subject  or  representing  a  group,  one  of  whose  permanent  members  Is  an  adopted  role  of  the 
subject. 

role  -  A  set  of  access  rights  that  a  subject  can  acquire. 

root  process  node  -  The  initial  process  node  created  when  a  user  logs  on  to  an  APSE  or  when  a  new 
job  is  created  via  the  CREATE_JOB  interface. 

secondary  relationship  -  An  arbitrary  connection  which  is  established  between  two  existing  nodes. 

security  level  -  [TCSEC]  The  combination  of  a  hierarchical  classification  and  a  set  of  non- 
hierarchical  categories  that  represents  the  sensitivity  of  information. 

source  node  -  The  node  from  which  a  relationship  emanates. 

start  position  (of  a  form  terminal)  -  The  position  of  a  form  identified  by  row  one.  column  one. 
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structural  node  -  A  node  without  contents.  Structural  nodes  are  used  strictly  as  holders  of 
relationships  and  attributes. 

subject  -  [TCSEC]  An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device,  that  causes 
information  to  flow  among  objects  or  changes  the  system  state.  In  the  CAIS,  a  subject  Is  always  a 
process. 

system-level  node  -  The  root  of  the  CAIS  primary  relationship  tree  which  spans  the  entire  node 
structure. 

target  node  -  The  node  at  which  a  relationship  terminates. 

task  *  [LRM]  A  task  operates  in  parallel  with  other  parts  of  the  program. 

termination  of  a  process  -  Termination  (see  [LRM]  9.4)  of  the  execution  of  the  subprogram  which 
is  the  main  program  (see  [LRM]  10.1)  of  the  process. 

token  -  An  internal  representation  of  an  identifier  which  can  be  manipulated  as  a  list  item. 

tool  -  [IEEE  -  software  tool]  A  computer  program  used  to  help  develop,  test,  analyze,  or  maintain 
another  computer  program  or  its  documentation;  for  example,  an  automated  design  tool,  compiler, 
test  tool,  or  maintenance  tool. 

top-level  node  -  A  structural  node  representing  the  user.  Each  user  has  a  top-level  node. 

track  -  (I)  An  open  node  handle  Is  guaranteed  always  to  refer  to  the  same  node,  regardless  of  any 
changes  to  relationships  that  could  cause  pathnames  to  become  Invalid  or  to  refer  to  different  nodes. 
An  open  node  handle  Is  said  to  track  the  node  to  which  it  refers.  (2)  Secondary  relationships. 

traversal  of  a  node  •  Traversal  of  a  relationship  emanating  from  the  node. 

traversal  of  a  relationship  -  The  act  of  following  a  relationship  from  its  source  node  to  its  target 
node. 

unique  primary  path  -  The  path  from  the  system-level  node  to  a  given  node  traversing  only 
primary  relationships.  Every  node  that  is  not  unobtainable  has  a  unique  primary  path. 

unique  primary  pathname  -  The  pathname  associated  with  the  unique  primary  path. 

unnamed  item  -  No  name  Is  associated  with  a  list  item. 

unnamed  list  -  A  list  whose  items  are  all  unnamed. 

unobtainable  -  A  node  Is  unobtainable  If  it  is  not  the  target  of  any  primary  relationship. 

user  -  An  individual,  project,  or  other  organizational  entity.  In  the  CAIS  it  is  associated  with  a  top- 
level  node. 

user  name  -  The  key  of  a  primary  relationship  of  the  predefined  relation  USER. 
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4.  GENERAL  REQUIREMENTS 


4.1.  Introduction 

The  CAIS  provides  interfaces  for  data  storage  and  retrieval,  data  transmission  to  and  from  external 
devices,  and  activation  of  programs  and  control  of  their  execution.  In  order  to  achieve  uniformity  in 
the  interfaces,  a  single  model  is  used  to  consistently  describe  general  data  storage,  devices  and 
executing  programs.  This  approach  provides  a  single  model  for  understanding  the  CAIS  concepts;  it 
provides  a  uniform  understanding  of  and  emphasis  on  data  storage  and  program  control:  and  it 
provides  a  consistent  way  of  expressing  interrelations  both  within  and  between  data  and  executing 
programs.  This  unified  model  is  referred  to  as  the  node  model. 

Section  4.2  discusses  how  the  interfaces  are  described  in  the  remainder  of  Section  4  and  in  Section  5. 
Section  4.3  describes  the  node  model.  Section  4.4  describes  the  mandatory  and  discretionary  access 
control  model  Incorporated  in  the  CAIS.  Section  4. 5  describes  limits  and  constraints  not  defined  by 
the  interfaces.  Section  5  provides  detailed  descriptions  of  the  interfaces.  Section  6  provides 
information  on  the  intended  use  of  this  document  and  relevant  keywords  for  use  by  automated 
document  retrieval  systems. 

Appendix  A  provides  descriptions  of  the  entities  predefined  In  the  CAIS.  This  appendix  constitutes  a 
mandatory  part  of  this  standard. 

Appendix  B  provides  a  set  of  the  Ada  package  specifications  which  have  been  organized  for 
compilation  of  the  CAIS  Interfaces.  Appendix  C  provides  a  set  of  the  corresponding  Ada  package 
bodies.  Appendix  D  provides  a  list  of  all  CAIS  procedures  and  functions  organized  by  the  packages  in 
which  they  appear. 


4.2.  Method  of  description 

The  specifications  of  the  CAIS  interfaces  are  divided  into  two  parts: 

a.  the  syntax  as  defined  by  a  canonical  Ada  package  specification,  and 

b.  the  semantics  as  defined  by  the  descriptions  both  of  the  general  node  model  and  or  the 
particular  packages  and  procedures. 

The  Ada  package  specifications  given  In  this  document  are  te  med  canonical  because  they  are 
representative  of  the  form  of  the  allowable  actual  Ada  package  specifications  in  any  particular  CAIS 
implementation.  The  packages  which  together  provide  an  Implementation  of  these  specifications  must 
have  indistinguishable  syntax  and  semantics  from  those  staled  herein. 


4.2.1.  Allowable  differences 

The  packages  which  together  provide  a  particular  implementation  of  the  CAIS  miM  have  t  he 
following  properties: 

a.  Any  Ada  program  that  Is  legal  and  not  erroneous  In  the  presence  of  the  canonical  package 
specifications  as  library  units  must  be  legai  and  not  erroneous  if  the  canonical  packages  are 
replaced  by  the  packages  of  a  particular  CAIS  implementation  and  the  names  of  additional 
library  units  required  for  the  Implementation  of  this  particular  CAIS  are  not  in  conflict 
with  the  names  of  library  units  required  b.v  the  Ada  program.  Note:  It  is  recommended. 
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although  not  required,  that  any  Ada  program  that  Is  Illegal  In  the  presence  of  the 
canonical  package  specifications  as  library  units  Is  also  illegal  If  the  canonical  packages  are 
replaced  by  the  packages  of  a  particular  CAiS  Implementation.] 

b.  The  CAIS  interfaces  provided  by  the  subprograms  declared  in  the  packages  of  a  particular 
CAIS  implementation  must  have  the  semantics  described  In  this  document  for  the 
corresponding  subprograms  In  the  canonical  package  specifications. 

The  actual  Ada  package  specifications  of  a  particular  implementation  may  differ  from  the  canonical 
specifications  as  long  as  properties  (a)  and  (b)  are  preserved. 


4.2.2.  Semantic  descriptions 

The  interface  semantics  are  described  In  most  cases  through  narrative.  These  narratlv  are  divided 
into  as  many  as  five  paragraphs.  The  Purpose  paragraph  describes  the  function  of  the  u.ierface.  The 
Parameters  paragraph  .briefly  describes  eaeh  of  the  parameters,  and  the  Exceptions  paragraph  briefly 
dcseribes  the  conditions  under  which  each  exception  Is  raised.  Any  relevant  information  that  does  not 
fall  under  one  of  these  three  headings  is  included  in  a  Notes  paragraph.  In  cases  where  an  interface  is 
overloaded  and  the  additional  versions  can  be  described  in  terms  of  the  basic  form  of  the  interface 
and  other  CAIS  interfaces,  these  versions  are  described  in  a  paragraph,  called  Additional  Interfaces, 
using  Ada.  This  method  of  presenting  the  semantics  of  the  Additional  Interfaces  is  a  conceptual 
model.  It  does  not  imply  that  the  Additional  Interfaces  must  be  Implemented  in  terms  of  the  existing 
ones  exactly  as  specified,  merely  that  their  behavior  is  equivalent  to  such  an  implementation.  The 
semantics  described  In  the  Purpose,  Parameters  and  Exceptions  apply  only  to  the  principal  Interface; 
the  Additional  Interfaces  may  have  additional  semantics  as  Implied  by  the  given  package  bodies. 


4.2.3.  Typographical  conventions 

This  document  follows  the  typographical  conventions  of  [LRM]  where  these  are  not  In  conflict  with 
those  of  a  MIL-STD.  In  particular: 

a.  boldface  type  Is  used  for  Ada  language  reserved  words, 

b.  UPPER  CASE  Is  used  for  Ada  language  Identifiers  which  are  not  reserved  words, 

c.  In  the  text,  syntactic  category  names  are  written  In  normal  typeface  with  any  embedded 
underscores  removed, 

d.  in  the  text,  where  reference  Is  made  to  the  actual  value  of  an  Ada  variable  (for  example,  a 
procedure  parameter),  the  Ada  name  Is  used  In  normal  typeface.  However,  where 
reference  Is  made  to  the  Ada  object  Itself  (see  [LRM]  3.2  for  this  use  of  the  word  object), 
then  the  Ada  name  is  given  in  upper  case,  including  any  embedded  underscores.  For 
example,  from  [LRM]  14.2.1  paragraphs  17,  18  and  19 

function  MODE(FII.E:  in  F!LE_TYPE)  return  FILE_MODE; 

Returns  the  current  mode  of  the  given  file, 
but 

The  exception  STATUS _  ERROR  Is  raised  If  the  file 
Is  not  open. 
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e.  at  the  place  where  a  technical  term  is  first  introduced  and  defined  in  the  text,  the  term  is 
given  In  an  italic  typeface. 


4.3.  CAIS  node  model 

The  CAIS  provides  interfaces  for  administering  entities  relevant  during  the  software  life-cycle  such  as 
files,  directories,  processes  and  devices.  These  entities  have  various  properties  and  may  have  a  variety 
of  interrelations.  The  CAIS  model  uses  the  concept  of  a  node  as  the  carrier  of  information  about  an 
entity.  It  uses  the  concept  of  a  relationship  for  representing  an  Interrelation  between  two  entitles 
and  the  concept  of  an  attribute  for  representing  a  property  of  an  entity  or  of  an  Interrelation. 

The  model  of  the  structure  underlying  the  CAIS  and  reflecting  the  Interrelations  of  entities  is  a 
directed  graph  of  nodes,  which  form  the  vertices  of  the  graph,  and  relationships,  which  form  the  edges 
of  the  graph.  This  model  is  a  conceptual  model.  It  does  not  imply  that  an  implementation  of  the 
CAIS  must  use  a  directed  graph  to  represent  nodes  and  their  relationships. 

Both  nodes  and  relationships  possess  attributes  describing  properties  of  the  entitles  represented  by 
nodes  and  of  interrelations  represented  by  relationships. 


4.3.1.  Nodes 

The  CAIS  identifies  three  different  kinds  of  nodes:  structural  nodes,  file  nodes  and  process  nodes.  A 
node  may  have  contents,  relationships  and  attributes.  The  contents  vary  with  the  kind  of  node.  If  a 
node  is  a  file  node,  the  contents  is  an  Ada  external  nie.  There  are  four  types  of  CAIS  supported  Ada 
external  files:  secondary  storage,  queue,  terminal,  and  magnetic  tape.  The  Ada  external  Tile  may 
represent  a  host  file,  a  device  (such  as  a  terminal  or  tape  drive)  or  a  queue  (as  used  for  process 
intercommunication).  If  a  node  Is  a  process  node,  the  contents  Is  a  representation  of  the  execution  of 
an  Ada  program.  If  a  node  is  a  structural  node,  there  Is  no  contents  and  the  node  is  used  strictly  as  a 
holder  of  relationships  and  attributes.  The  kind  of  a  node  Is  a  predefined  and  Implicitly  established 
attribute  on  every  relationship  which  points  to  the  node. 

Nodes  can  be  created,  renamed,  accessed  (as  part  of  other  operations),  and  deleted. 


4.3.2.  Processes 

A  process  Is  the  CAIS  mechanism  used  to  represent  the  execution  of  an  Ada  program.  A  process  is 
represented  as  the  contents  of  a  process  node.  The  process  node  and  Its  attributes  and  relationships 
are  also  used  to  bind  to  an  execution  the  resources  (such  as  files  and  devices)  required  by  the  process. 
Taken  together,  the  process  node,  its  attributes,  relationships  and  contents  are  used  in  the  CAIS  to 
manage  the  dynamics  of  the  execution  of  a  program.  Each  time  execution  of  a  program  is  initiated,  a 
process  node  Is  created,  the  process  Is  created,  the  necessary  resources  to  support  the  execution  of  the 
program  are  allocated  to  the  process,  and  execution  is  started.  The  newly  created  process  is  railed 
the  initiated  process,  while  the  process  which  caused  the  creation  of  that  process  Is  called  the 
initiating  process. 

A  single  CAIS  process  represents  the  execution  of  a  single  Ada  program,  even  when  that  program 
includes  multiple  tasks.  Within  the  process,  Ada  tasks  execute  In  parallel  (proceed  independently! 
and  synchronize  In  ao-ordance  with  the  rules  In  (LRMj  A,  paragraph  5: 

Parallel  tasks  may  be  implemented  on  multicomputers,  multiprocessors,  or  with  interleaved 
execution  on  a  single  physical  processor.  On  the  other  hand,  whenever  an  implementation  can 
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detect  that  the  same  effect  can  be  guaranteed  if  parts  of  the  actions  of  a  given  [Ada|  task  are 
executed  by  different  physical  processors  acting  In  parallel.  It  may  choose  to  execute  them  in  this 
way:  in  such  a  case  several  physical  processors  Implement  a  single  logical  processor. 

When  a  task  makes  a  CAJS  call,  execution  of  that  task  Is  blocked  until  the  CAJS  call  returns  control 
to  the  task.  Other  tasks  in  the  same  process  may  continue  to  execute  In  parallel,  subject  to  the  Ada 
tasking  rules.  If  calls  on  CAJS  interfaces  are  enacted  concurrently,  the  CAIS  does  not  specify  their 
order  of  execution. 

Processes  arc  analogous  to  Ada  tasks  In  that  they  execute  logically  In  parallel,  have  mechanisms  for 
interprocess  synchronization,  and  can  exchange  data  with  other  processes.  However,  processes  and 
Ada  tasks  are  dissimilar  In  certain  critical  ways.  Data,  procedures  or  tasks  in  one  process  cannot  be 
directly  referenced  from  another  process.  Also,  while  tasks  In  a  program  are  bound  together  prior  to 
execution  time  (at  compile  or  link  time),  processes  are  not  bound  together  except  by  cooperation  using 
CAIS  facilities  at  run  time. 


4.3.3.  Input  and  output 

Ada  Input  and  output  In  (LRM|  M  Involves  the  transfer  of  data  to  and  from  Ada  external  files.  CAIS 
input  and  output  uses  the  same  model  and  involves  the  transfer  of  data  to  and  from  the  contents  of 
CAIS  file  nodes.  These  file  nodes  may  represent  disk  or  other  secondary  storage  flies,  magnetic  tape 
drives,  terminals,  or  queues. 

CAIS  file  nodes  represent  Information  about  and  contain  Ada  external  flies.  The  underlying  model  for 
the  contents  or  such  a  node  Is  that  of  a  file  of  data  Items,  accessible  either  sequentially  or  directly  by 
some  Index.  The  packages  specified  In  Section  5.3  provide  facilities  that  operate  on  CAIS  external 
flies. 

Implementations  of  the  standard  Ada  packages  SEQUENTIAL _IO,  DIRECT_IO,  and  TEXT_IO 
specified  in  the  [LRM]  that  operate  upon  CAIS  files  are  to  be  constructed  such  that  they  meet  the 
Ada  standard  and  for  CRI  '.ATE  and  OPEN  procedures: 

1.  The  semantics  of  th  •  use  of  the  default  value  of  the  FORM  parameter  FORM  :  IN  string 
:  =  ""  is  specified  within  the  context  of  the  node  model. 

2.  The  syntax  and  semantics  of  the  non  empty  FORM  parameter  is  specified  within  the 
context  of  the  NODE  model. 

3.  Nothing  In  the  Implementation  can  violate  the  concistancy  of  the  CAIS  NODE  model. 

The  interfaces  In  the  package  MAGNETIC  _ TAPE  have  been  modeled  on  the  American  National 
Standards  Institute  standards  In  [ANSI  78). 


4.3.4.  Relationships  and  relations 

The  relationships  of  CAIS  nodes  form  the  edcs  of  a  directed  graph;  they  are  used  to  build 
conventional  hierarchical  directory  and  process  structures  (see  Section  5.1.5  STRUCTURAI,_  NODES 
and  Section  5.2.2  PROCESS  __  CONTROL)  a'  well  as  arbitrary  dlrected-graph  structures. 
Relationships  are  unidirectional  and  are  said  to  emanate  from  a  source  node  and  to  terminate  at  a 
target  node.  A  relationship  may  also  have  attributes  describing  properties  of  the  relationship. 

Because  any  node  may  have  many  relationships  representing  many  different  classes  of  connections. 
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the  concept  of  a  relation  is  introduced  to  categorize  the  relationships.  Relations  identify  the  nature 
of  relationships,  and  relationships  are  Instances  of  relations.  Certain  basic  relations  are  predefined  by 
the  CAJS.  Their  semantics  are  explained  in  the  following  sections.  Additional  predefined  relations  are 
introduced  In  Section  5  and  are  listed  in  Appendix  A.  Relations  may  also  be  defined  by  a  user.  The 
CAiS  associates  only  the  relation  name  with  user-defined  relations;  no  other  semantics  are  supported. 

Rach  relationship  is  identified  by  a  relation  name  and  a  relationship  key.  The  relation  name 
identifies  the  relation,  and  the  relationship  key  distinguishes  between  multiple  relationships  each 
bearing  the  same  relation  name  and  emanating  from  a  given  node. 

Nodes  in  the  environment  are  attainable  by  following  relationships.  Operations  arc  provided  to 
traverse  a  relationship,  that  is,  to  follow  a  relationship  from  its  source  node  to  its  target  node. 

4.3.4. 1.  Kinds  of  relationships 

There  are  two  kinds  of  relationships:  primary  and  secondary.  When  a  node  is  created,  an  initial 
relationship  is  established  from  some  other  node  to  the  newly  created  node.  This  initial  relationship  is 
called  the  primary  relationship  to  this  new  node,  and  the  source  node  of  this  initial  relationship  is 
called  the  parent  node.  In  addition,  the  new  node  will  be  connected  back  to  this  parent  via  a 
relationship  of  the  predefined  relation  PARENT.  There  is  no  requirement  that  all  primary 
relationships  emanating  from  a  node  have  the  same  relation  name.  Primary  relationships  form  a 
strictly  hierarchical  tree;  that  Is,  for  every  node  (except  the  root)  there  Is  one  and  only  one  sequence 
of  primary  relationships  leading  to  it  from  the  node  that  is  the  root  of  the  tree.  No  cycles  can  be 
constructed  using  only  primary  relationships. 

The  primary  relationship  Is  broken  by  DELETE_NODE  or  DELETE_TREE  operations.  After 
deletion  of  the  primary  relationship  to  a  node,  the  node  is  said  to  be  unobtainable.  A  non-existing 
node  is  one  which  has  never  been  created.  RENAME  operations  may  be  used  to  make  the  primary 
relationship  to  a  node  emanate  from  a  different  node  which  becomes  the  new  parent  of  the  node.  The 
operations  DELETE  _  NODE,  DELETE_TREE,  RENAME,  and  the  operations  creating  nodes  are  the 
only  operations  that  manipulate  primary  relationships.  They  maintain  a  slate  in  which  each  node  has 
exactly  one  parent  and  a  unique  primary  pathname  (see  Section  4.3.5). 

Secondary  relationships  are  arbitrary  connections  which  may  be  established  between  two  existing 
nodes;  secondary  relationships  may  form  an  arbitrary  directed  graph.  User-defined  secondary 
relationships  are  created  with  the  LINK  procedure  and  broken  with  the  UNLINK  procedure. 
Secondary  relationships  may  exist  to  unobtainable  nodes. 

4.3. 4.2.  Basic  predefined  relations 

The  CAIS  predefines  certain  relations.  Relationships  belonging  to  a  predefined  relation  cannot  be 
created,  modified,  or  deleted  by  means  of  the  CAIS  interfaces  and  their  relationship  keys  are  the 
empty  string,  except  where  explicitly  noted.  The  semantics  of  the  predefined  relations  which  are  basic 
to  the  node  model,  as  well  as  related  concepts  of  the  CAIS,  are  explained  In  this  Section  and  Section 
4.4.  The  basic  predefined  relations  explained  in  this  Section  are  USER,  DEVICE.  JOB. 
CURRENT_  JOB,  CURRENT_USER  and  CURRENT_  NODE. 

The  CAJS  node  model  Incorporates  the  notion  of  a  user.  A  user  may  be  an  Individual,  project,  or 
other  organizational  entity;  this  notion  is  not  equated  with  only  an  Individual  person.  Each  user  has 
one  top-level  node.  This  top-level  node  Is  a  structural  node  which  represents  the  user  and  from  it  the 
user  can  access  other  structural,  file  and  process  nodes. 
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The  CAIS  node  model  Incorporates  the  notion  of  a  system.  This  notion  provides  the  means  of 
administering  all  the  entitles  represented  within  one  CAIS  implementation.  This  notion  Implies  the 
existence  of  a  system-level  node  which  acts  as  the  root  of  the  CAJS  primary  relationship  tree  spanning 
the  entire  node  structure.  Each  top-level  node  Is  reachable  from  the  system-level  node  along  a  primary 
relationship  of  the  predefined  relation  USER  emanating  from  the  system-level  node.  The  key  of  this 
relationship  Is  the  user  name.  Each  user  name  has  a  top-level  node  associated  with  it.  The  system- 
level  node  cannot  be  accessed  explicitly  by  the  user  via  the  CAJS  Interfaces.  It  may  only  be 
manipulated  by  Interfaces  outside  the  CAIS,  e.g.,  to  add  new  relationships  of  the  predefined  relation 
USER  emanating  from  the  system-level  node. 

The  CAIS  node  model  Incorporates  the  notion  of  devices.  Each  device  is  described  by  a  file  node.  This 
file  node  is  reachable  from  the  system-level  node  along  a  primary  relationship  of  the  predefined 
relation  DEVICE  emanating  from  the  system-level  node.  The  key  of  this  relationship  Is  the  device 
name.  The  CAIS  does  not  define  interfaces  for  creating  nodes  which  represent  devices;  such  interfaces 
are  to  be  provided  outside  the  CAIS. 

The  CAIS  node  model  Incorporates  the  notion  of  a  Job.  When  a  user  logs  onto  the  Al'SE  or  calls  the 
CREATE_JOB  procedure,  a  root  process  node  Is  created  which  often  represents  a  command 
Interpreter  or  other  user-communication  process.  It  Is  left  to  each  CAJS  Implementation  to  set  up  a 
methodology  for  users  to  log  onto  the  APSE  and  for  enforcing  any  constraints  that  limit  the  top-level 
nodes  at  which  users  may  log  on.  After  logging  onto  the  APSE,  the  user  will  be  regarded  by  the  CAJS 
as  the  user  associated  with  the  top-level  node  at  which  he  logged  on.  A  process  node  tree,  spanned  by 
primary  relationships,  develops  from  the  root  process  node  as  other  processes  (called  dependent 
processes)  are  initiated  for  the  user.  A  particular  user  may  have  several  root  processes  nodes 
concurrently.  Each  corresponding  process  node  tree  Is  referred  to  as  a  job.  The  predefined  JOB 
relation  Is  provided  for  locating  each  of  the  rcot  process  nodes  from  the  user  s  top-level  node.  A 
primary  relationship  of  the  predefined  relation  IOB  emanates  from  each  user's  top-level  node  to  the 
root  process  node  of  each  of  the  user's  jobs.  The  key  of  this  relationship  Is  assigned  by  the  mechanism 
of  interpreting  the  LATEST_KEY  constant  (see  Section  4.3.5)  unless  otherwise  specified  in  the 
CREATE_JOB  procedure  call. 

While  the  CAIS  does  not  Specify  an  Interface  for  creating  the  initial  root  process  node  when  a  user 
logs  onto  the  APSE,  the  effect  Is  to  be  the  same  as  a  call  to  the  CREATE_JOB  procedure.  The 
secondary  relationships  which  the  Implementation  must  establish  are  found  in  TABLE  DC.  In 
particular,  secondary  relationships  of  the  predefined  relations  USER  and  DEVICE  must  be 
established,  with  the  appropriate  user  and  device  names  as  keys.  These  relationships  emanate  from 
the  root  process  node  being  created  to  an  Implementation-defined  subset  of  top-level  nodes  and  file 
nodes  representing  devices,  respectively.  Dependent  process  nodes  in  the  job  inherit  these 
relationships.  File  nodes  representing  devices  and  top-level  nodes  of  other  users  can  be  reached  from 
a  process  node  via  a  relationship  of  the  relation  DEVICE  or  USER  and  a  relationship  key  which  is 
interpreted  as  the  respective  device  or  user  name. 

CURRENT_JOB,  CURRENT _ USER,  and  CURRENT_ NODE  are  predefined  relations  which 
provide  a  convenient  means  for  Identifying  other  CAIS  nodes.  The  relationship  of  the  predefined 
relation  CURRENT _  JOB  always  points  to  the  root  process  node  of  a  process  node's  Job.  The 
relationship  of  the  predefined  relation  CURRENT _  USER  always  points  to  the  user's  top-level  node. 
The  relationship  of  the  i  ledeflned  relation  CURRENT_NODE  can  be  used  to  point  to  a  node  which 
represents  the  processY  current  focus  or  context  for  Its  activities.  The  process  node  can  thus  use  the 
CURRENT _  NODE  foi  a  base  node  when  specifying  pathnames  (see  Section  4.3.5).  The  CAIS 
requires  that,  when  a  root  process  node  Is  created,  It  has  a  relationship  of  the  predefined  relation 
CURRENT_ NODE  pointing  to  the  top-level  node  for  the  user. 
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The  node  model  makes  use  of  the  concept  of  a  current  process.  This  concept  Is  Implicit  In  all  calls  to 
CA1S  operations  and  refers  to  the  process  for  the  currently  executing  program  making  the  call.  It 
defines  the  context  in  which  the  parameters  are  to  be  interpreted.  In  particular,  pathnames  are 
determined  in  the  context  of  the  current  process. 

4.3.5.  Paths  and  pathnames 

Every  accessible  node  may  be  reached  by  following  a  sequence  of  relationships;  this  sequence  is  called 
the  path  to  the  node.  A  path  starts  at  a  known  (not  necessarily  top-level)  node  and  follows  a 
sequence  of  relationships  to  a  desired  node.  The  path  from  the  system-level  node  to  a  given  node 
traversing  only  primary  relationships  is  called  the  unique  primary  path  to  the  given  node. 

Paths  are  specified  using  a  pathname  syntax.  Starting  from  a  given  node,  a  path  is  followed  by 
traversing  a  sequence  of  relationships  until  the  desired  node  is  reached.  The  pathname  for  this  path 
is  made  up  of  the  concatenation  of  the  names  of  the  traversed  relationships  in  the  same  order  in 
which  they  are  traversed. 

The  syntax  of  a  pathname  Is  a  sequence  of  path  elements,  each  path  element  representing  the 
traversal  of  a  single  relationship.  A  path  element  Is  an  apostrophe  (pronounced  "tick")  followed  by  a 
relation  name  and  a  parenthesized  relationship  key. 

Relation  names  and  relationship  keys  follow  the  syntax  of  Ada  identifiers.  Upper  and  lower  case  are 
treated  as  equivalent  within  such  Identifiers.  If  the  relationship  key  of  a  path  element  is  the  empty 
string,  the  parentheses  may  be  omitted.  Thus.  'PARENT  and  'PARENTO  refer  to  the  same  node. 

The  CAIS  predefines  the  relation  DOT.  If  the  relation  name  In  a  path  element  is  DOT,  then  the  path 
element  may  be  represented  simply  by  a  dot  ('.')  followed  by  the  relationship  key.  Thus, 
'DOT(TRACKER)  Is  the  same  as  .TRACKER.  Relationship  keys  of  relationships  of  the  DOT  relation 
may  not  be  the  empty  string.  Instances  of  the  DOT  relation  may  be  manipulated  by  the  user  within 
access  right  constraints.  Relationships  of  the  DOT  relation  are  not  restricted  to  be  primary 
relationships  and  are  not  associated  with  any  other  CAJS-specIflc  semantics. 

The  starting  point  for  Interpretation  of  a  pathname  Is  always  the  current  process  node.  A  pathname 
may  begin  simply  with  a  relationship  key,  not  prefixed  by  either  an  apostrophe  or  .  This  is  taken 
to  mean  interpretation  following  a  relationship  emanating  from  the  current  node  with  the  relation 
name  DOT  and  with  the  given  key.  Thus  LANDING  _SYSTEM  is  the  same  its 
CURRENT  _  NODE.LANDING  _SYSTKM. 

For  example,  all  of  the  following  are  legal  node  pathnames,  and  they  would  all  refer  to  the  same  node 
If  the  relationship  of  the  ptedefined  relation  points  to  the  same  node  as  'USRR(JONES). TRACKER 
and  the  relationship  of  the  predefined  relation  points  to  the  same  node  as  ’USER(JONES): 

a.  LANDING  _SYSTEM'WITH_UNIT(RADAR) 

b.  'USER(  JONES). TRACKER.  LANDING  _SYSTEM'WITI  I  _  UNIT(  RADAR) 

c.  'CURRENT  _  USER.  TRACK  ER.  LANDING  _  SYSTEM 'WITH  UNIT(RADAR) 


A  pathname  may  also  be  a  .  This  is  interpreted  as  referring  to  the  current  process  node. 

By  convention,  a  relationship  key  ending  in  '#'  is  taken  to  represent  the  LATEST _ KEY 
(lexicographically  last).  When  creating  a  node  or  relationship,  use  of  to  end  the  final  relationship 
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key  of  a  pathname  will  cause  a  relationship  key  t<  be  automatically  assigned,  lexicographically 
following  all  previous  relationship  keys  for  the  same  elation  and  initial  relationship  key  character 
sequence  of  relationships  emanating  from  that  particular  node. 

Identification  of  a  node  Is  provided  by  a  pathname  or  by  a  given  node  and  an  identification  of  a 
relationship  emanating  from  the  given  node  by  means  of  its  relation  name  and  relationship  key.  The 
phrase  to  identify  means  to  provide  an  Identification  lor  a  node.  A  node  identification  is  considered 
an  illegal  identification  if  either  the  pathname  or  the  relationship  key  or  the  relation  name  is 
syntactically  illegal  with  respect  to  the  syntax  defined  in  Table  I.  An  Illegal  identification  is  treated  as 
an  identification  for  a  non-existing  node. 

A  pathname  Implies  traversal  of  a  node  If  a  relationship  emanating  from  the  node  is  traversed; 
consequently  all  nodes  on  the  path  to  a  node  are  traversed,  while  the  node  at  the  end  of  the  path  is 
not  traversed.  An  Identification  that  would  require  traversal  of  an  unobtainable  or  Inaccessible  node  is 
treated  as  the  identification  for  a  non-existing  node. 

The  pathname  associated  with  the  unique  primary  path  Is  called  the  unique  primary  pathname  of  the 
node.  The  unique  primary  pathname  of  the  node  is  syntactically  Identical  to,  and  therefore  can  be 
used  as,  a  pathname  whose  interpretation  starts  at  the  current  process  node.  It  always  starts  with 
USRR(  user  _  name). 

When  Identifying  a  node,  use  of  to  end  any  relationship  key  In  the  pathname  is  interpreted  as 
the  relationship  key  of  an  existing  relationship,  lexicographically  following  ail  other  keys  for  the  same 
relation  and  Initial  relationship  key  character  sequence  of  relationships  emanating  from  that  particular 
node. 
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Table  I.  Pathname  BNF 


path  name::=  relationship _key{path_element}  | 
path  _element{path_e!ement}  |: 

path_element::=  relation  _ name  [  (  [  relationship _ key  ]  )  )  | 
.relationship  _  key 


relation  _  name::  =  identifier 
relationship_key::=  identifier  |  (  identifier  |  # 


Note:  the  relation  name  DOT  must  have  a  non-empty  relationship  key. 


Notation: 

1.  Words  -  syntactic  categories 

2.  (  ]  -  optional  items 

3.  {  }  -  an  item  repeated  zero  or  more  times 

4.  |  -  separates  alternatives 


4.3.0.  Attributes 

Both  nodes  and  relationships  may  have  attributes  which  provide  information  about  the  node  or 
relationship.  Attributes  are  Identified  by  an  attribute  name.  Each  attribute  has  a  name  and  has  a 
list  of  the  values  assigned  to  It,  represented  using  the  LIST _ UTILITIES  type  called  LIST_TYPE 
(see  Section  5.4.1). 

Relation  names  and  attribute  names  both  have  the  same  form  (that  is,  the  syntax  of  an  Ada 
identifier).  Relation  names  and  node  attribute  names  for  a  given  node  must  be  different  from  each 
other:  relationship  attribute  names  are  in  a  separate  name  space. 

The  CAIS  predefines  certain  attributes  which  are  discussed  In  Section  5  and  listed  in  Appendix 
A.  Predefined  attributes  cannot  be  created,  modified  or  deleted  by  the  user,  except  where  explicitly 
noted.  The  user  can  also  create  and  manipulate  user-defined  attributes  (see  Section  5.1.3). 
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4.4.  Discretionary  and  mandatory  access  control 

The  CAIS  specifies  mechanisms  for  discretionary  and  mandatory  access  control  (see  [TCSEC).  These 
specifications  are  only  recommendations.  Alternate  discretionary  or  mandatory  access  control 
mechanisms  can  be  substituted  by  an  implementation  provided  that  the  semantics  of  all  interfaces  in 
Section  5  (with  the  exception  of  Section  5.1.4)  are  Implemented  as  specified. 

In  the  CAJS,  access  control  refers  to  all  the  aspects  of  controlling  access  to  information.  It  consists 
of: 


a.  access  control  rights  Descriptions  of  the  kinds  of  operations  which  can  be  performed. 

b.  access  control  rules  The  rules  describing  the  correlations  between  access  rights  and  those 
rights  required  for  an  Intended  operation. 

c.  access  checking  The  operation  of  checking  granted  access  rights  against  those  rights 
required  for  the  Intended  operation  according  to  the  access  control  rules,  and  either 
permitting  or  denying  the  intended  operation. 


All  of  the  Information  required  to  perform  access  checking  Is  collectively  referred  to  as  access  control 
information.  The  resulting  restrictions  placed  on  certain  kinds  of  operations  by  access  control  are 
called  access  rights  constraints. 


4.4.1.  Node  access 

In  the  CAIS,  the  following  operations  constitute  access  to  a  node: 

a.  reading  or  writing  of  the  contents  of  the  node, 

b.  reading  or  writing  of  attributes  of  the  node, 

c.  reading  or  writing  of  relationships  emanating  from  a  node  or  or  their  attributes,  and 

d.  traversing  a  node  (see  Section  4.3.5). 

The  phrase  "reading  relationships"  Is  a  convenient  short-hand  meaning  either  traversing  relationships 
or  reading  their  attributes.  To  access  a  node,  then,  means  to  perform  any  of  the  ;ibove  access 
operations.  The  phrase  "to  obtain  access"  to  a  node  means  being  permitted  to  perform  certain 
operations  on  the  node  within  access  right  constraints.  Access  to  a  node  by  means  of  a  pathname  can 
only  be  achieved  if  the  current  process  has  the  rrspective  access  rights  to  the  node  as  well  as  to  any 
node  traversed  on  the  path  to  the  node. 

In  the  CAIS.  the  following  operations  do  not  con-titute  access  to  a  node:  closing  node  handles  to  a 
node,  opening  a  node  with  Intent  EXISTENCE  (s< •->  TABLE  V),  reading  or  writing  of  relationships  of 
which  a  node  Is  the  target  or  of  the  attributes  of  -uch  relationships,  querying  the  kind  of  a  node  and 
querying  the  status  of  node  handles  to  a  node. 

A  node  is  inaccessible  if  the  current  process  do  not  have  sufficient  discretionary  access  control 
rights  to  have  knowledge  of  the  node’s  existence  <  if  mandatory  access  controls  prevent  information 
flow  from  the  node  to  the  current  process.  The  piwpcrty  of  inaccessibility  is  always  relative  to  the 
access  rights  of  the  currently  executing  process,  while  the  property  of  unobtainabillty  is  a  property  of 
the  node  alone. 
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4.4.2.  Discretionary  access  control 

Discretionary  access  control  is  a  means  of  restricting  access  to  objects  based  on  the  identity  of 
subjects  and/or  groups  to  which  they  belong.  The  controls  are  discretionary  in  the  sense  that  a 
subject  with  certain  access  permission  is  capable  of  passing  that  permission  (perhaps  indirectly) 
on  to  any  other  subject  [TCSEC]. 

In  the  CAiS,  an  objict  is  any  node  to  be  accessed  and  a  subject  is  any  process  (acting  on  ihe  behalf  of 
a  given  user)  performing  an  operation  requiring  access  to  an  object.  Discretionary  access  control  Is 
used  to  limit  access  to  nodes  by  processes  running  programs  on  behalf  of  users  or  groups  of  users. 

An  object  can  have  established  for  it  a  secondary  relationship  of  the  predefined  relation  ACCESS 
which  specifies  the  kinds  of  operations  which  may  be  performed  on  it.  A  process  node  may  have  a 
secondary  relationship  of  the  ADOPTED  _  ROLE  relation  established  to  the  same  target  node  as  a 
predefined  relation  relationship.  The  information  provided  by  these  two  kinds  of  relationships 
determines  the  approved  access  rights  which  the  process  has  to  the  object  (see  Section  4. 4. 2. 3).  When 
the  process  tries  to  open  the  object  node,  the  access  rights  implied  by  the  INTENT  parameter  (see 
Section  5.1)  are  checked  against  these  approved  access  rights  to  determine  whether  the  process  ran 
perform  the  operation  on  that  node. 

4. 4. 2.1.  Establishing  grantable  access  rights 

An  object  may  be  the  source  node  of  zero  or  more  secondary  relationships  of  the  predefined  relation 
ACCESS  (called  access  relationships).  Each  access  relationship  has  a  predefined  attribute,  called 
GRANT,  which  specifies  what  access  rights  to  the  object  are  grantable  to  processes  (subjects). 

In  order  to  limit  the  set  of  nodes  to  which  access  relationships  can  be  established,  the  CAIS 
discretionary  access  control  model  requires  that,  upon  creation  of  a  root  process  node,  secondary 
relationships  of  the  predefined  relation  ALLOW  _ ACCESS  be  created.  These  relationships  emanate 
from  the  created  root  process  node  to  an  Implementation-defined  set  of  nodes.  The  CAIS 
implementation  must  establish  at  least  the  secondary  relationship  of  the  predefined  relation 
ALLOW  _  ACCESS  with  the  user  name  as  key  from  the  root  process  node  to  the  user  top-level  node. 
All  such  relationships  are  inherited  by  the  process  nodes  created  under  the  root  process  node. 

Access  relationships  and  GRANT  attributes  are  established  for  objects  In  one  of  two  ways:  using  the 
interfaces  provided  in  the  package  ACCESS_ CONTROL  or  at  node  creation. 

The  SET_ ACCESS_CONTROL  procedure  can  be  used  by  a  process  to  establish  an  access 
relationship  between  two  nodes  and  to  set  the  value  of  the  GRANT  attribute.  This  procedure  can  also 
be  used  to  change  the  value  of  the  GRANT  attribute  of  an  existing  access  relationship. 

Access  relationships  are  also  established  at  node  creation.  The  ACCESS _ CONTROL  parameter 
provides  the  necessary  information  in  two  parts.  One  part  provides  relationship  keys  which  are  used 
to  identify  the  nodes  which  will  be  the  targets  of  the  new  access  relationships.  If  the  current  process 
node  has  a  relationship  of  the  relation  ALLOW _  ACCESS  whose  key  is  one  of  the  keys  given  in  the 
parameter,  then  the  node  identified  by  that  relationship  becomes  the  target  of  a  new  access 
relationship  from  the  created  node. 

The  other  part  of  the  ACCESS  _ CONTROL  parameter  gives  a  set  of  access  rights  for  each 
relationship  key  These  access  rights  become  the  value  of  the  GRANT  attribute  of  the  access 
relationship  created  with  the  corresponding  key. 

The  ACCESS_CONTROL  parameter  specifies  the  initial  access  control  information  to  be  established 
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for  a  node  being  created  using  named  Ada  aggregate  syntax;  that  is,  it  consists  of  a  list  of  items  each 
of  which  has  a  name  (Identifying  a  target  node  for  an  access  relationship)  followed  by  a  list  of  values 
for  the  GRANT  attribute. 

For  every  relationship  key  named  In  the  list  for  which  the  current  process  node  has  a  relationship  of 
the  predefined  relation  ALLOW  _  ACCESS,  a  relationship  of  the  predefined  relation  ACCESS  with 
the  given  relationship  key  and  the  given  access  rights  value  for  Its  GRANT  attribute  value  is  created 
from  the  new  node  to  the  target  of  the  relationship  of  the  predefined  relation  ALLOW  _  NCCKSS 

4. 4. 2. 2.  Adopting  »  role 

In  the  CAIS,  a  role  is  associated  with  a  set  of  access  rights  that  a  subject  can  acquire  when  it  acts 
under  authority  of  that  role.  Each  role  Is  associated  with  a  CAJS  user,  a  program  being  executed,  or  a 
particular  group  of  users,  programs  or  subgroups.  A  subject  (process)  may  act  under  the  authority  of 
several  roles.  Roles  can  be  acquired  dynamically. 

In  the  CAIS  a  role  Is  represented  by  a  node;  the  associated  access  rights  are  determined  by  access 
relationships  as  described  In  the  following  sections.  This  node  may  be  a  top-level  node  representing  a 
user,  a  node  containing  the  executable  image  of  a  program,  or  a  structural  node  representing  a  group. 
The  structural  node  representing  a  group  has  relationships  emanating  Rom  it  to  the  nodes  which 
represent  the  group's  members. 

Each  group  member  is  identified  either  by  a  primary  relationship  of  the  predefined  relation 
PERMANENT  _  MEMBER  or  by  a  secondary  relationship  of  the  predefined  relation 
POTENTIAL _ MEMBER  emanating  from  the  group  node.  The  phrase  permanent  member  of  a  group 
refers  to  any  node  reachable  from  a  node  representing  the  group  via  primary  relationships  or  the 
predefined  relation  PERMANENT  _ MEMBER.  The  relation  PERMANENT  _ MEMBER  may  be  used 
to  create  a  hierarchy  of  nodes  representing  roles  by  defining  members  of  a  group  that  are  themselves 
groups.  A  user  top-level  node  may  not  be  the  target  of  a  primary  relationship  of  the  predefined 
relation  PERMANENT _ MEMBER  emanating  from  a  group  node  due  to  the  restriction  that  user 
top-level  nodes  can  only  have  a  primary  relationship  from  the  system-level  node. 

Secondary  relationships  of  the  predefined  relation  POTENTIAL _  MEMBER  are  used  to  identify  those 
members  that  may  dynamically  acquire  membership  In  the  group.  The  phrase  potential  member  of  a 
group  refers  to  any  node  that  Is  the  target  of  a  relationship  of  the  predefined  relation 
POTENTIAL _ MEMBER  from  that  group  or  from  any  of  that  group's  permanent  members. 

When  a  process  adopts  a  particular  role,  a  secondary  relationship  of  the  predefined  relation 
ADOPTED _  ROLE  Is  created  from  the  process  node  to  the  node  representing  the  role.  There  may  be 
multiple  relationships  of  the  predefined  relation  ADOPTED _  ROLE  emanating  from  a  process  node. 
Roles  are  adopted  either  at  creation  of  the  process  node  or  explicitly.  When  a  process  is  created,  it 
implicitly  adopts  the  role  represented  by  the  nie  node  containing  an  executable  image  of  the  program 
it  is  executing.  When  a  root  process  node  Is  created,  it  Implicitly  adopts  the  role  represented  by  Its 
current  user  node.  When  any  process  node  Is  created,  it  implicitly  inherits  the  relationships  of  the 
relation  ADOPTED _  ROLE  of  the  node  of  Its  creating  process.  A  process  may  explicitly  adopt  a  role 
associated  with  a  group  using  the  ADOPT  procedure  (Section  5. 1 .4.4).  For  a  process  to  adopt  a  role 
associated  with  a  given  group,  a  node  representing  some  other  adopted  role  of  the  process  must  be  a 
potential  member  of  the  given  group. 
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4.4. 2.3.  Evaluating  acceaa  rights 

The  value  of  the  GRANT  attribute  is  a  list  whose  syntax  Is  given  by  the  BNF  in  TABLE  II.  The 
necessary  right  is  an  access  right,  and  the  resulting  rights  are  a  list  of  access  rights.  An  access  right 
name  has  the  syntax  of  an  Ada  identifier. 


Table  II.  GRANT  attribute  value  BNF 


grant_attribute_value::  =  (  [  grant_item  {,grant_item}]) 

grant_item::=  ([necessary_right=>]  resulting_rlghls_list) 

necessary _ right::  =  identifier 

resulting_rights_llst::=  identifier  | 

(  identifier  {,  identifier}) 


Notation: 

1.  Words  -  syntactic  categories 

2.  (  )  -  optional  Items 

3.  {  }  -  an  item  repealed  zero  or  more  times 

4.  |  -  separates  alternatives 


The  syntax  is  consistent  with  that  given  in  Section  5.4.  The  interfaces  in  Section  5.4  can  be  used  to 
construct  and  manipulate  values  of  the  GRANT  attribute. 

Checking  of  discretionary  access  control  rights  involves  relevant  grant  items  and  approved  access 
rights,  both  of  which  are  derived  from  the  values  of  GRANT  attributes.  For  a  given  subject  and 
object,  relevant  grant  items  are  the  grant  items  in  values  of  GRANT  attributes  of  relationships  of  the 
relation  ACCESS  emanating  from  the  object  and  pointing  at  any  node  representing  a  role  which  is  an 
adopted  role  of  the  process  subject  or  representing  a  group  one  of  whose  permanent  members  is  an 
adopted  role  of  the  process  subject.  Approved  access  rights  are  access  rights  whose  names  appear  in 
resulting  rights  lists  of  relevant  grant  Items  for  which  either  (I)  the  necessary  right  is  null  or  (2)  the 
necessary  right  Is  an  approved  access  right. 


For  example,  given  a  process  node  SUBJECT,  an  object  OBJECT,  and  two  nodes  ROEEl  and  ROI.E2 
representing  roles,  the  following  relationships  might  exist: 

a  a  relationship  or  the  relation  ACCESS  from  OBJECT  to  ROI.EI  with  a  GRANT  attribute 
value  of  (REAI >MAII.=  XREAI),  WRITE)). 

b.  a  relationship  of  the  relation  ACCESS  from  OBJECT  to  ROI.E2  with  a  GRANT  attribute 
value  of  (REAOMAIL). 
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r.  a  relationship  of  the  relation  ADOPTED  _  ROLE  from  SUBJECT  to  ROLEt.  and 

d.  a  relationship  of  the  relation  .ADOPTED _ ROLE  from  SUBJECT  to  ROLE2. 

The  relevant  grant  items  are  READMAIL  and  READMAIL=>(READ,  WRH'E).  The  approved 
access  rights  for  SUBJECT  to  access  OBJECT  are  (l)  READMAIL  because  the  necessary  rights  of  the 
relevant  grant  item  of  the  access  relationship  to  ROLE2  is  null  and  (2)  READ  and  WRITE  because 
the  necessary  right.  READMAIL,  of  the  relevant  grant  item  of  the  access  relationship  to  ROLEl  is 

approved.  FIGURE  1  shows  a  graphic  representation  of  these  relationships. 


Figure  1.  Access  relationships 

Access  rights  may  be  user-defined,  but  certain  access  rights  have  special  significance  m  CAIS 
operations.  In  particular,  the  CAIS  recognizes  the  access  rights  given  in  Table  ill  and  the  kinds  of 
access  for  which  they  are  necessary  or  sufficient. 
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Table  ID.  Predefined  access  rights 

EXISTENCE  The  minimum  access  rights  without  which  the  object  is  inaccessible  to  (he  subject. 

Without  additional  access  rights  the  subject  may  neither  read  nor  write  attributes, 
relationships  or  contents  of  the  object. 

READ  _  RELATIONSHIPS 

The  subject  may  read  attributes  of  relationships  emanating  from  the  object  or  use 
it  for  traversal  to  another  node;  the  access  right  EXISTENCE  is  implicitly  granted. 
This  access  right  is  necessary  to  open  the  object  with  intent 
READ  _  RELATIONSHIPS. 

WRITE_  RELATIONSHIPS 

The  subject  may  create  or  delete  relationships  emanating  from  the  object  or  may 
create,  delete,  or  modify  attributes  of  these  relationships;  the  access  right 
EXISTENCE  is  implicitly  granted.  This  access  right  is  necessary  to  open  the  object 
with  intent  WRITE _ RELATIONSHIPS. 

APPEND  _  RELATIONSHIPS 

The  subject  may  create  relationships  emanating  from  the  object  and  attributes  of 
these  relationships;  the  access  right  EXISTENCE  is  implicitly  granted.  This  access 
right  Is  necessary  to  open  the  object  with  intent  APPEND _ RELATIONSHIPS. 

READ  _  ATTRIBUTES 

The  subject  may  read  attributes  of  the  object;  the  access  right  EXISTENCE  is 
Implicitly  granted.  This  access  right  is  necessary  to  open  the  object  with  intent 
READ  _  ATTRIBUTES. 

WRITE  _  ATTRIBUTES 

The  subject  may  create,  write,  or  delete  attributes  of  the  object;  the  access  right 
EXISTENCE  is  Implicitly  granted.  This  access  right  is  necessary  to  open  the  object 
with  Intent  WRITE _  ATTRIBUTES. 

APPEND  _  ATTRIBUTES 

The  subject  may  create  attributes  of  the  object;  the  access  right  EXISTENCE  is 
implicitly  granted.  This  access  right  is  necessary  to  open  the  object  with  intent 
APPEND  _  ATTRIBUTES. 

READ  _CONTENTS 

The  subject  may  read  contents  of  the  object;  the  access  right  EXISTENCE  is 
implicitly  granted.  This  access  right  Is  necessary  to  open  the  object  with  intent 
READ  _  CONTENTS. 

WRITE  _  CONTENTS 

The  subject  may  write  contents  of  the  object;  the  access  right  EXISTENCE  Is 
Implicitly  granted.  This  access  right  is  necessary  to  open  the  object,  with  intent 
WRITE__ CONTENTS  granted.  This  access  right  is  necessary  to  open  the  object 
with  intent  READ _ CONTENTS. 

APPEND  _  CONTENTS 

The  subject  may  append  contents  of  the  object;  the  access  right  EXISTENCE  is 
implicitly  granted.  This  access  right  Is  necessary  to  open  the  object  with  intent 
APPEND  CONTENTS. 
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READ  This  Is  the  union  of  READ  _  RELATIONSHIPS,  READ  _  ATTRIBUTES, 

READ _  CONTENTS  and  EXISTENCE  access  rights.  This  access  right  is  necessary 
to  open  the  object  with  Intent  READ.  It  Is  sufficient  to  open  the  object  with  Intent 
READ _  RELATIONSHIPS,  READ  _  ATTRIBUTES  or  READ  CONTENTS. 

WRITE  This  is  the  union  of  WRITE  _  RELATIONSHIPS,  WRITE_  ATTRIBUTES. 

WRITE_CONTENTS  and  EXISTENCE  access  rights.  This  access  right  is 
necessary  to  open  the  object  with  Intent  WRITE.  It  Is  sufficient  to  open  the  object 
with  Intent  WRITE_  RELATIONSHIPS,  WRITE  _  ATTRIBUTES  or 
WRITE  _  CONTENTS. 

APPEND  This  Is  the  union  of  APPEND _ RELATIONSHIPS,  APPEND_ ATTRIBUTES 
APPEND  _ CONTENTS  and  EXISTENCE  access  rights.  This  access  right  Is 
necessary  to  open  the  object  with  intent  APPEND.  It  is  sufficient  to  open  the 
object  vith  intent  APPEND  _  RELATIONSHIPS,  APPEND _ ATTRIBUTES  or 
APPE'  l)_CONTENTS. 

EXECUTE  The  subject  may  create  a  process  that  takes  the  content'  of  the  object  as  its| 
executable  image;  the  access  right  EXISTENCE  is  implicitly  granted.  This  access 
right  Is  necessary  to  open  the  object  with  Intent  EXECUTE. 

CONTROL  The  subject  may  modify  access  control  information  of  the  object;  the  access  right 
EXISTENCE  Is  implicitly  granted.  This  access  right  is  necessary  to  open  the  object 
with  Intent  CONTROL. 


4.4. 2.4.  Discretionary  access  checking 

CAIS  access  control  rules  state  that  any  access  right  required  for  a  subject  to  access  an  object  must 
be  contained  in  the  set  of  approved  access  rights  of  that  object  with  respect  to  that  subject.  The 
CAIS  model  allows  discretionary  access  checking  to  be  performed  at  the  time  a  node  handle  is  opened. 
At  this  point  access  rights  Implied  by  the  INTENT  parameter  of  the  open  operation  must  be  a  subset 
of  the  approved  access  rights.  If  this  Is  not  the  case,  the  operation  Is  terminated  and  an  exception  is 
raised.  For  subsequent  access  using  the  node  handle,  the  access  rights  required  may  be  compared  to 
the  rights  Implied  by  the  intent,  rather  than  the  approved  access  rights. 


4.4.3.  Mandatory  access  control 

Mandatory  access  control  provides  access  controls  based  directly  on  a  comparison  of  the 
Individual's  clearance  or  authorization  for  the  information  and  the  classification  or  sensitivity 
designation  of  the  Information  being  sought  [TCSEC], 

A  mandatory  access  control  classification  may  be  either  a  hierarchical  classification  level  or  a  non- 
hierarchical  category.  A  hierarchical  classification  level  Is  chosen  from  an  ordered  set  of  classification 
levels  and  represents  either  the  sensitivity  of  the  object  or  the  trustworthiness  of  the  subject.  In 
hierarchical  classification,  the  reading  of  Information  flows  downward  towards  less  sensitive  areas, 
while  the  creating  of  Information  flows  upward  towards  more  trustworthy  Individuals.  A  subject  may 
obtain  read  access  to  an  object  if  the  hierarchical  classification  of  the  subject  Is  greater  than  or  equal 
to  that  of  the  object.  In  turn,  to  obtain  write  access  to  the  object,  a  subject's  hierarchical 
classification  must  be  less  than  or  equal  to  the  hierarchical  classification  of  the  object. 
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Each  subject  and  object  is  assigned  zero  or  more  non-hierarchlcal  categories  which  represent 
coexisting  classifications.  A  subject  may  obtain  read  access  to  an  object  if  the  set  of  non-hierarchical 
categories  assigned  to  the  subject  contains  each  category  assigned  to  th<  object.  Likewise,  a  subject 
may  obtain  write  access  to  an  object  if  each  of  the  non-hierarchical  categories  assigned  to  the  subject 
are  included  in  the  set  of  categories  assigned  to  the  object. 

A  subject  must  satisfy  both  hierarchical  and  non-hierarchical  access  rights  rules  to  obtain  access  to  an 
object. 

In  the  CAIS,  subjects  are  CAIS  processes,  while  an  object  may  be  any  CAiS  node.  Operations  are 
CAJS  operations  and  are  classified  as  read,  write,  or  read/write  operations.  Access  checking  is 
performed  at  the  time  the  operation  is  requested  by  comparing  the  classification  of  the  subject  with 
that  of  the  object  with  respect  to  the  type  of  operation. 

4.4.3. 1.  Labeling  of  CAIS  nodes 

The  labeling  of  nodes  Is  provided  by  predefined  node  attributes.  A  predefined  attribute,  called 
SUBJECT_CLASSIFlCATION,  is  assigned  to  each  process  node  and  represents  the  process- 
classification  as  a  subject.  A  predefined  attribute,  called  OBJECT  _  CLASSIFICATION,  is  assigned  to 
each  node  and  represents  the  node's  classification  as  an  object.  These  attributes  have  a  limited 
function  and  cannot  be  read  or  written  directly  through  the  CAIS  Interfaces.  The  value  of  the 
attribute  is  a  parenthesized  list  containing  two  Items,  the  hierarchical  classification  level  and  the  non- 
hierarchical  category  list.  The  hierarchical  classification  is  a  keyword  member  of  the  ordered  set  of 
hierarchical  classification  keywords.  The  non-hlerarchlcal  category  list  is  a  list  of  zero  or  more 
keyword  members  of  the  set  of  non-hierarchical  categories.  The  hierarchical  classification  level  set  and 
the  non-hierarchical  category  set  are  implementation-defined.  For  example,  the  following  are  possible 
classification  attribute  values: 

(TOP _ SECRET,  (MAIL _ USER.  OPERATOR,  STAFF)) 

(UNCLASSIFIED.  ()) 

(SECRET.  (STAFF)) 


The  BNF  for  the  value  of  a  classification  attribute  (and  of  the  LEVEL  parameter  which  provides  it  at 
node  creation)  is  given  in  Table  IV. 
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Table  IV.  Classification  attribute  value  HNF 


object__classiflcation  =  classification 
subject_ classification  ::=  classification 
classification  ::=  {  hierarchical  _ classification, 
non _ hierarchical _categories  ) 
hierarchical  _ classification  ::=  keyword 

non _ hierarchical _ categories  ::=  (  [  keyword  {  ,  keyword  }  ]  ) 
keyword  ::=  identifier 


Notation: 

1.  Words  -  syntactic  categories 

2.  [  ]  -  optional  items 

3.  {  }  -  an  item  repeated  zero  or  more  times 

4.  |  •  separates  alternatives 


4.4.3.2.  Labeling  of  process  nod  eg 

When  a  root  process  is  created.  It  Is  assigned  subject  and  object  classification  labels.  The  method  by 
which  these  Initial  labels  are  assigned  Is  not  specified;  however,  the  labels  shall  accurately  represent 
security  levels  of  the  specific  [users/  with  which  they  are  associated  [TCSEC].  When  any  non-root 
(dependent)  process  node  is  created,  the  creator  may  specify  the  classification  attributes  associated 
with  the  node.  If  no  classification  Is  specified,  the  classification  Is  Inherited  from  the  creator.  The 
assigned  classification  must  adhere  to  the  requirements  for  mandatory  access  control  ov>t  write 
operations. 

4.4.3.3.  Labeling  of  non-procesa  nodes 

When  a  non-process  object  is  created,  It  Is  assigned  an  object  classification  label.  The  classification 
label  may  be  specified  In  the  create  operation,  or  It  may  be  inherited  from  the  parent.  The  assigned 
classification  must  adhere  to  the  requirements  for  mandatory  access  control  over  write  operations. 

4. 4.3.4.  Labeling  of  nodes  for  devices 

Certain  file  nodes  representing  devices  may  have  a  range  of  classification  levels.  The  classification 
label  of  the  node  of  the  first  process  opening  a  handle  to  one  or  these  nodes  Is  assigned  to  the  file  node 
while  there  are  any  open  node  handles  to  the  flic  node.  Only  when  all  open  node  handles  h:ive  been 
closed  can  a  new  classification  label  be  assigned  to  the  file  node. 

The  range  of  classification  levels  Is  specified  by  two  predefined  CAJS  node  attributes.  The  attribute 
HIGHEST _CIjASSIFICATION  defines  the  highest  allowable  object  classification  label  that  may  be 
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assigned  to  the  file  node.  The  attribute  LOWEST _ CLASSIFICATION  defines  the  lowest  allowable 
object  classification  label  that  may  be  assigned  to  the  file  node. 

When  a  file  node  representing  the  device  is  opened,  the  device  inherits  its  security  classification  label 
from  the  first  process  performing  the  open  operation.  If  It  is  not  possible  to  label  the  node 
representing  the  device  within  the  bounds  of  the  attributes  HIGHEST_  CLASSIFICATION  and 
LOWKST_CLASSIFiCATION.  the  operation  fails  by  raising  the  exception 
SECURITY  _  VIOLATION. 

4. 4. 3. 5.  Mandatory  access  checking 

When  access  control  is  enforced  for  a  given  operation,  mandatory  access  control  rules  are  checked.  If 
mandatory  access  controls  are  not  satisfied,  the  operation  terminates  by  raising  the  exception 
SECURITY_ VIOLATION,  except  where  the  Indication  of  failure  constitutes  violation  of  mandatory 
access  control  rules  for  "read"  operations.  In  which  case  NAME_ ERROR  may  be  raised. 


4.5.  Pragmatics 

This  section  provides  several  minimum  values  for  implementation-determined  quantities  and  sizes. 


4.5.1.  Pragmatics  for  CA1S  node  model 

Several  private  types  are  defined  as  part  of  the  CAIS  node  model.  The  actual  implementation  of 
these  types  may  vary  from  one  CAIS  Implementation  to  the  next.  However,  it  is  important  to 
establish  certain  minimum  values  for  each  type  to  enhance  portability. 

NAME_  STRING 

At  least  255  characters  must  be  supported  in  a  CAIS  pathname. 

RELATIONSHIP  _  KEY 

At  least  80  leading  characters  must  be  significant  in  a  relationship  key. 

ATTRIBUTE _ NAME,  RELATION _  NAME 

At  least  80  leading  characters  must  be  significant  In  attribute  and  relation  names. 

Tree  height  At  least  10  levels  of  hierarchy  must  be  supported  for  the  primary  relationships. 

Record  size  number 

At  least  2**  15-1  bits  per  record  must  be  supported. 

Open  node  count 

Each  process  must  be  able  to  have  at  least  127  nodes  open  simultaneously. 

List  At  least  2**  15-1  bits  per  list  must  be  supported. 
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4.5.2.  Pragmatic*  for  SEQUENTIAL  IQ 

A  CAIS  Implementation  must  support  generic  instantiation  of  this  package  with  any  (non-limited) 
constrained  Ada  type  whose  maximum  size  In  bits  (as  defined  by  the  attribute 
FXEMENT_TYPE‘SIZE)  Is  at  least  2**l5-l.  A  conforming  implementation  must  also  support 
instantiation  with  unconstrained  record  types  which  have  default  constraints  and  a  maximum  size  In 
bits  of  at  least  2**15-1.  It  may  (but  need  not)  use  variable  length  elements  to  conserve  space  in  thi 
external  file. 


4.5.3.  Pragmatic*  for  DIRECT  IQ 

Each  element  of  a  direct-access  file  is  selected  by  an  Integer  Index  of  type  COUNT.  A  conforming 
implementation  must  at  least  support  a  range  of  Indices  from  one  to  2**15-1. 

A  CAIS  implementation  must  support  generic  instantiation  of  this  package  with  any  (non-limited) 
constrained  Ada  type  whose  maximum  size  in  bits  (as  defined  by  the  attribute 
ELEMENT_TYPE‘SIZE)  is  at  least  2**15-l.  A  conforming  Implementation  must  also  support 
instantiation  with  unconstrained  record  types  which  have  default  constraints  and  a  maximum  size  in 
bits  of  at  least  2MIH.  It  may  (but  need  not)  use  variable  length  elements  to  conserve  space  in  the 
external  file. 


4.5.4.  Pragmatic*  for  TEXT  IQ 

A  CAIS  Implementation  must  support  files  with  at  least  2*M5-1  records/lines  in  total  and  at  least 
2**15-1  lines  per  page.  A  CAIS  Implementation  must  support  at  least  255  columns  per  line. 
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5.  DETAILED  REQUIREMENTS 


The  following  detailed  requirements  shall  be  fulfilled  In  a  manner  consistent  with  the  model 
descriptions  given  in  Section  4  of  this  standard. 


5.1.  General  node  management 

This  section  describes  the  CAIS  Interfaces  for  the  general  manipulation  of  nodes,  relationships  and 
attributes.  These  Interfaces  are  defined  in  five  CAJS  packages:  NODE_  DEFINITIONS  defines  types, 
subtypes,  exceptions,  and  constants  used  throughout  the  CAJS;  NODE_MANAGEMKNT  defines 
interfaces  for  general  operations  on  nodes  and  relationships;  ATTRIBUTES  defines  interfaces  for 
general  operations  on  attributes;  ACCESS _ CONTROL  defines  interfaces  for  setting  and  adopting 
access  rights;  and  STRUCTURAL_  NODES  defines  Interfaces  for  the  creation  of  structural  nodes. 

Specialized  interfaces  for  the  manipulation  of  process  and  file  nodes  and  of  their  relationships  and 
attributes  are  defined  In  Sections  5.2  and  5.3,  respectively. 

To  simplify  manipulation  by  Ada  programs,  an  Ada  type  NODE _ TYPE  is  defined  for  values  that 
represent  an  Internal  handle  for  a  node  (referred  to  as  a  node  handle.  Objects  of  this  type  can  be 
associated  with  a  node  by  means  of  CAIS  procedures,  causing  an  open  node  handle  to  be  assigned  to 
the  object.  While  such  an  association  Is  In  effect,  the  node  handle  Is  said  to  be  open;  otherwise,  the 
node  handle  Is  said  to  be  closed.  Most  procedures  expect  either  a  parameter  of  type  NODE  _ TYPE, 
a  pathname,  or  a  combination  of  a  base  node  (specified  by  a  parameter  BASE  of  type  NODE_TYPE) 
and  a  path  element  relative  to  It,  to  Identify  a  node. 

An  open  node  handle  is  guaranteed  always  to  refer  to  the  same  node,  regardless  of  any  changes  to 
relationships  that  could  cause  pathnames  to  become  Invalid  or  to  refer  to  different  nodes.  This 
behavior  is  referred  to  as  the  tracking  of  nodes  by  open  node  handles. 


5.1.1.  Package  NOFlF,  DEFINITIONS 

This  package  defines  the  Ada  type  NODE_TYPE.  It  also  defines  certain  enumeration  and  string 
types  and  exceptions  useful  for  node  manipulations. 

type  nodejtype  la  limited  private  ; 

type  NODEJCIMS  ia  (FILE,  STRUCTURAL,  PROCESS); 

type  INTENT  SPECIFICATION  is 

(EXISTENCE.  READ.  WRITE.  READ_ATTRIBUTES ,  WRITE_ ATTRIBUTES. 

APPEND  ATTRIBUTES.  READ  RELATIONSHIPS,  WRITE  RELATIONSHIPS. 

APPEND_RELATIONSHIPS,  READ  CONTENTS,  WRITE~CONTENTS. 

APPEND_CONTENTS.  CONTROL.  EXECUTE.  EXCLUSIVE  READ, 

EXCLUSIVE  WRITE.  EXCLUS I VE_READ_ATTR I BUTES . 

EXCLUSIVE j»RITE_ATTRIBUTES ,  "eXCLUSIVEAPPENDATTRIBUTES  , 

EXCLUSIVE jlEAD  RELATIONSHIPS ,  EXCLUSIVE  WRITE  RELATIONSHIPS , 
EXCLUSIVE_AFPEND_RELATIONSHIPS ,  EXCLUSIVE_READ_CONTENTS , 

EXCLUSIVE_WRITE_CONTENTS ,  EXCLUSIVE_APPEND_CONTENTS . 

EXCLUS  I  VEjrONTROL)  ; 

type  intention  ia  array  (positive  range  <»  of  intent  specification; 

subtype  name  string  is  STRING; 
subtype  relationshipkey  ia  string; 
aubtype  relatiqn_name  is  string; 
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subtype  formstrihc  is  string; 


NODE_TYPE  describes  the  type  for  node  handles.  NODE_KIND  Is  the  enumeration  of  the  kinds 
of  nodes.  INTENT  _ SPECIFICATION  describes  the  usage  of  node  handles  and  is  further  explained 
in  Section  5.1.2.  INTENTION  is  the  type  of  the  parameter  INTENT  of  CAJS  procedures  which  open 
or  change  the  intent  of  a  node  handle,  as  further  explained  in  Section  5.1.2. 

NAME  _  STRING,  RELATIONSHIP  _  KEY,  RELATION_  NAME,  and  FORM  _  STRING  are 
subtypes  for  pathnames,  relationship  keys,  and  relation  names,  as  well  as  for  form  strings  (see  [LRM] 
14).  Value  of  these  string  subtypes  are  subject  to  certain  syntactic  restrictions  whose  violation  causes 
exceptions  to  be  raised. 

CURRENTUSER  ;  constant  HAKE _ STRING  :=  •  'CURR£NT_USER* ; 

currekt'hqde  :  constant  NAME~STRING  :=  ••CTJRREXT~HODE"; 

currext'process  :  constant  naxe~stri  ng  ;=•:•; 

latest  key  :  constant  relationshipjcey :  = 

DEFAULTRELATION:  Constant  RELATIONMAXE  ;=  "DOT*; 
no  delay  :  constant  DURATION-  —'FIRST 


CURRENT _ USER,  CURRENT _ NODE,  and  CURRENT_ PROCESS  are  standard  pathnames  for 
the  current  user’s  top-level  node,  current  node,  and  current  process,  respectively.  LATICST_KEY 
and  DEFAULT  _  RELATION  are  standard  names  for  the  latest  key  and  the  default  relation  name, 
respectively.  NO  _ DELAY  Is  a  constant  of  type  DURATION  (see  [LRM]  9.6)  used  for  time  limits. 


NAMEERROR 
USEERROR 
STATUSERROR 
LOCKERROR 
I NTEMTVI OLATI ON 
ACCESSVI OLATI ON 
SECURITY  VIOLATION 


exception ; 
exception; 
exception ; 
exception ; 
exception ; 
exception; 
exception ; 


NAME_  ERROR  is  raised  whenever  an  attempt  Is  made  to  access  a  node  via  a  pathname  or  node 
handle  while  the  node  does  not  exist,  it  Is  unobtainable,  discretionary  access  control  constraints  for 
knowledge  of  existence  of  a  node  are  violated,  or  mandatory  access  controls  for  ’read'  operations  are 
violated.  This  exception  takes  precedence  over  ACCESS_  VIOLATION  and 
SECURITY  _  VIOLATION  exceptions. 

USE_ ERROR  Is  raised  whenever  a  restriction  on  the  use  of  an  interface  is  violated. 

STATUS _ ERROR  Is  raised  whenever  the  open  status  or  a  node  handle  does  not  conform  to 
expectations. 

LOCK  _  ERROR  is  raised  whenever  an  attempt  Is  made  to  modify  or  lock  a  locked  node. 

INTENT_VTOLATION  Is  raised  whenever  an  operation  Is  attempted  on  an  open  node  handle  which 
Is  In  violation  of  the  Intent  associated  with  the  open  node  handle. 

ACCESS_ VIOLATION  Is  raised  whenever  an  operation  is  attempted  which  violates  access  right 
constraints  other  than  knowledge  of  existence  of  the  node.  ACCESS _  VIOLATION  is  raised  only  if 
the  conditions  for  NAME _ ERROR  are  not  present. 
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SECURITY_ VIOLATION  is  raised  whenever  an  operation  is  attempted  which  violates  mandatory 
access  controls  for  write'  operations.  SECURITY_ VIOLATION  is  raised  only  if  the  conditions  for 
other  exceptions  are  not  present. 


5.1.2.  Package  NODE _ MANAGEMENT 

This  package  defines  the  general  primitives  for  manipulating,  copying,  renaming  and  deleting  nodes 
and  their  relationships. 

The  operations  defined  in  this  package  are  applicable  to  all  nodes,  relationships  and  attributes  except 
where  explicitly  stated  otherwise.  These  operations  do  not  Include  the  creation  of  nodes.  The  creation 
of  structural  nodes  Is  performed  by  the  CREATE_  NODE  procedures  or  package 
STRUCTURA1,_ NODES  (see  Section  5.1.5),  the  creation  of  nodes  for  processes  is  performed  by 
INVOKE_  PROCESS,  SPAWN  _  PROCESS  and  CREATEJOB  of  package 
PROCESS  _  CONTROL  (see  Section  5.2.2),  and  the  creation  of  nodes  for  flies  Is  performed  by  tne 
CREATE  procedures  of  the  input  and  output  packages  (see  Section  5.3). 

Three  CA1S  Interfaces  for  manipulating  node  handles  are:  OPEN  opens  a  node  handle,  CLOSE  closes 
the  node  handle,  and  CHANGE_ INTENT  alters  the  specification  of  the  intention  of  node  handle 
usage.  In  addition,  GET_PARENT,  GET_  CURRENT  _  NODE,  GET_NEXT, 

OPEN  _FILE_  NODE  and  the  node  creation  procedures  also  open  node  handles.  These  Interfaces 
perform  access  synchronization  In  accordance  with  an  Intent  specified  by  the  parameter  INTENT. 

Operations  which  open  node  handles  or  cl>  mge  their  intent  are  central  to  general  node  administration 
since  they  manipulate  node  handles  and  most  other  interfaces  take  node  handles  as  parameters. 
While  such  other  interfaces  may  also  be  i  rovlded  In  overloaded  versions,  taking  pathnames  as  node 
identification,  these  overloaded  versions  a  e  to  be  understood  as  including  Implicit  OPEN  calls  with 
appropriate  Intent  specification  and  a  d  fault  TIME _  LIMIT  parameter.  Subsequent  uses  or  the 
phrase  'open  operation'  may  refer  to  any  <■  the  OPEN,  C I ET_ CURRENT _ NODE,  GET _ PARENT, 
GET _ NEXT  and  OPEN  _FILE_  NODE  operations. 

One  or  more  of  the  Intents  defined  In  TABLE  V  can  be  expressed  by  the  INTENT  parameters. 


Table  V.  Intents 

EXISTENCE:  The  established  access  right  for  subsequent  operations  is  to  query  properties  of  the 
node  handle  and  existence  of  the  node  only.  Locks  on  the  node  have  no  delaying 
effect. 

READ,  EXCLUSIVE _ READ: 

Open  and  CHANGE _ INTENT  operations  are  delayed  ir  the  node,  its  contents, 
attributes  or  relationships  are  locked  against  read  operations.  The  established  access 
right  for  subsequent  operations  Is  to  read  node  contents,  attributes  and 
relationships. 

For  EXCLUSIVE_RKAD,  the  node  is  locked  against  opens  with  any  write  Intent  as 
specified  in  FIGURE  2.  Open  and  change_ intent  operations  are  additionally 
delayed  if  there  are  open  node  handles  to  the  node  with  write  intent. 

WRITE,  EXCLUSIVE _ WRITE: 

Open  and  change_lntent  operations  are  delayed  If  the  node,  its  contents,  attributes 
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or  relationships  are  locked  against  write  operations.  The  established  access  right  for 
subsequent  operations  Is  to  write,  create  or  append  to  node  contents,  attributes  and 
relationships. 

For  EXCLUSIVE  _  WRITE,  the  node  Is  locked  against  opens  with  any  read,  write 
or  append  Intent  as  specified  in  FIGURE  2.  Open  and  change_  intent  operations 
are  additionally  delayed  if  there  are  open  node  handles  to  the  node  with  read,  write 
or  append  intent. 

READ _ CONTENTS,  EXCLUSIVE _  READ  _ CONTENTS: 

Open  and  change  _  intent  operations  are  delayed  If  the  node  or  Its  contents  are 
locked  against  read  operations.  The  established  access  right  for  subsequent 
operations  is  to  read  the  node  contents. 

For  EXCLUSIVE _  READ  _ CONTENTS,  the  node  contents  are  locked  against  all 
opens  with  write  intent  as  specified  In  FIGURE  2.  Open  and  change_lntent 
operations  are  additionally  delayed  if  there  are  open  node  bandies  to  the  node  with 
Intent  to  write  its  contents. 

WRITE _ CONTENTS,  EXCLUSIVE_WRITE_ CONTENTS: 

Open  and  change_lntent  operations  are  delayed  if  the  node  or  Its  contents  are 
locked  against  write  operations.  The  established  access  right  for  subsequent 
operations  is  to  write  or  append  to  the  node  contents. 

For  EXCLUSIVE _ WRITE _ CONTENTS,  the  node  contents  are  locked  against 
opens  with  read,  write  or  append  Intent  as  specified  In  FIGURE  2.  Open  and 
change_intent  operations  are  additionally  delayed  if  there  are  open  node  handles  to 
the  node  with  Intent  to  read,  write  or  append  to  Its  contents. 

APPEND _ CONTENTS,  EXCLUSIVE _ APPEND _ CONTENTS: 

Open  and  change_lnlent  operations  are  delayed  if  the  node  or  Its  contents  are 
locked  against  append  operations.  The  established  access  right  for  subsequent 
operations  Is  to  append  to  the  node  contents.  j 

For  EXCLUSIVE_ APPEND_CONTENTS,  the  node  contents  are  locked  against 
opens  with  append  or  write  intent  as  specified  in  FIGURE  2.  Open  and 
change_intent  operations  are  additionally  delayed  If  there  are  open  node  handles  to 
the  node  with  intent  to  append  or  write  to  its  contents. 

READ  _  ATTRIBUTES,  EXCLUSIVE  _  READ  _ ATTRIBUTES: 

Open  and  change _ intent  operations  are  delayed  If  the  node  or  Its  attributes  are 
locked  against  read  operations.  The  established  access  right  for  subsequent 
operations  Is  to  read  node  attributes. 

For  EXCLUSIVE_ READ _ ATTRIBUTES,  the  node  is  locked  against  opens  with 
intent  to  write  attributes  as  .specified  in  FIGURE  2.  Open  and  change_ intent 
operations  are  additionally  delayed  if  there  are  open  node  handles  to  the  node  with 
Intent  to  write  attributes. 

WRITE  _  ATTRIBUTES,  EXCLUSIVE _ WRITE _  ATTRIBUTES: 

Open  and  change_ Intent  operations  are  delayed  If  the  node  or  its  attributes  are 
locked  against  write  operations.  The  established  access  right  for  subsequent 
operations  is  to  modify  and  create  node  attributes. 
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For  EXCLUSIVE_WRITE_ ATTRIBUTES,  the  node  is  locked  against  opens  with 
intent  to  read,  write  or  append  attributes  as  specified  in  FIGURE  2.  Open  and 
change_inlent  operations  are  additionally  delayed  if  there  are  open  node  handles  to 
the  node  with  intent  to  read,  write  or  append  attributes. 

APPEND_ ATTRIBUTES.  EXCLUSIVE_  APPEND  _  ATTRIBUTES: 

Open  and  change_ Intent  operations  are  delayed  if  the  node  or  its  attribute's  are 
locked  against  append  operations.  The  established  access  right  for  subsequent 
op<  rations  is  to  create  node  attributes. 

For  EXCLUSIVE _ APPEND  _  ATTRIBUTES,  the  node  is  locked  against  opens 
with  intent  to  write  or  append  attributes  as  specified  In  FIGURE  2.  Open  and 
change_ Intent  operations  are  additionally  delayed  If  there  are  open  node  handles  to 
the  node  with  Intent  to  write  or  append  attributes. 

READ _ RELATIONSHIPS,  EXCLUSIVE _ READ _  RELATIONSHIPS: 

Open  and  change _  intent  operations  are  delayed  If  the  node  or  Its  relationships  are 
locked  against  read  operations.  The  established  access  right  for  subsequent 
operations  is  to  read  node  relationships,  including  their  attributes. 

For  EXCLUSIVE_ READ_ RELATIONSHIPS,  the  node  is  locked  against  opens 
with  intent  to  write  relationships  as  specified  in  FIGURE  2.  Open  and 
change _  intent  operations  are  additionally  delayed  if  there  are  open  node  handles  to 
the  node  with  intent  to  write  relationships. 

WRITE _ RELATIONSI TIPS,  EXCLUSIVE _ WRITE _ RELATIONSHIPS: 

Open  and  change^ intent  operations  are  delayed  if  the  node  or  Its  relationships  are 
locked  against  write  operations.  The  established  access  right  for  subsequent 
operations  Is  to  write  or  create  node  relationships.  Including  their  attributes. 

For  EXCLUSIVE  _WRITE_  RELATIONSHIPS,  the  node  Is  locked  against  opens 
with  Intent  to  read,  write  or  append  relationships  as  specified  in  FIGURE  2.  Open 
and  change_lntont  operations  are  additionally  delayed  If  there  are  open  node 
handles  to  the  node  with  Intent  to  read,  or  write  append  relationships. 

APPEND_  RELATIONSHIPS,  EXCLUSIVE_ APPEND  _ RELATIONSHIPS: 

Open  and  change_lntent  operations  are  delayed  If  the  node  or  its  relationships  are 
locked  against  append  operations.  The  established  access  right  for  subsequent 
operations  is  to  create  node  relationships,  including  their  attributes. 

For  EXCLUSrVE_ APPEND_ RELATIONSHIPS,  the  node  is  locked  against  opens 
with  Intent  to  write  or  apixtnd  relationships  as  specified  In  FIGURE  2.  Open  and 
change _ Intent  operations  are  additionally  delayed  If  there  are  open  node  handles  to 
the  node  with  Intent  to  write  or  append  relationships. 

CONTROL,  EXCLUSIVE _CONTROL: 

Open  and  change  __ intent  operations  are  delayed  if  the  node  or  its  relationships  are 
locked  against  write  or  control  operations.  The  established  access  right  for 
subsequent  operations  is  to  read,  write  or  append  access  control  Information. 

For  EXCLUSIVE_CONTROL,  the  node  is  locked  against  opens  to  read,  write,  or 
append  relationships  or  to  read,  write,  or  append  access  control  information  as 
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specified  In  FIGURE  2.  Open  and  change _  intent  operations  are  additionally 
delayed  if  there  are  open  node  handles  to  the  node  with  Intent  to  read,  write  or 
append  relationships  or  to  read,  write  or  append  access  control  information. 

EXECUTE:  Open  and  change_intent  operations  are  delayed  if  the  node  contents  are  locked 

against  read  operations.  The  established  access  right  for  subsequent  operations  is 
the  permission  to  initiate  a  process  taking  the  node  contents  as  executable  image. 


Open  node  handles  can  block  other  attempts  to  open  other  node  handles  or  to  change  the  Intent  of 
other  node  handles  according  to  the  rules  demonstrated  in  FIGURE  2. 
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Figure  2.  Matrix  of  access  synchronization  constraints 
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5. 1.2.1.  Opening  a  node  handle 


procedure  open (NODE: 

NAME: 

INTENT 


in  out  N0DE_TYFE; 
in  NAME~STRING; 

in  INTENTION  : = 

(1  =>  READ); 

TIME  LIMIT:  in  DURATION  :=  NO  DELAY); 


procedure  open  (node: 

BASE: 

KEY: 

RELATION: 

INTENT: 

TIME  LIMIT: 


in  out  NODE_TYPE ; 
in  NODE_TYPE ; 

in  RELATIONSHIPJCEY; 

in  RELATIONNAME : = 

DEFAULT_RELATION; 
in  INTENTION  :=  (1  =>  READ): 

in  DURATION  :=  NO  DELAY); 


Purpose: 

These  procedures  return  an  open  node  handle  in  NODE  to  the  node  identified  by  the  pathname 
NAME  or  BASE/KEY/RELATION,  respectively.  The  INTENT  parameter  determines  the  access 
rights  available  for  subsequent  uses  of  the  node  handle;  It  also  establishes  access  synchronization 
with  other  users  of  the  node.  The  TIME_ LIMIT  parameter  allows  the  specification  of  a  time 
limit  for  the  delay  Imposed  on  OPEN  by  the  existence  of  locks  on  the  node.  A  delayed  OPEN 
call  completes  after  the  node  is  unlocked  or  the  specified  time  limit  has  elapsed.  In  the  latter 
case,  the  exception  LOCK _ ERROR  is  raised. 


Parameters: 


NODE 

NAME 

BASE 

KEY 

RELATION 

INTENT 

TIME  LIMIT 


is  a  node  handle,  Initially  closed,  to  be  opened  to  the  identified  node, 
is  the  pathname  identifying  the  node  to  be  opened. 

Is  an  open  node  handle  to  a  base  node  for  node  identification. 

Is  the  relationship  key  for  node  identification. 

Is  the  relation  name  for  node  identification. 

Is  the  intent  of  subsequent  operations  on  the  node;  the  actual  parameter  takes  the 
form  of  an  array  aggregate. 

Is  a  value  of  type  DURATION,  specifying  a  time  limit  for  the  delay  on  waiting  for 
the  unlocking  of  a  node  In  accordance  with  the  desired  INTENT. 


Exceptions: 

NAME _ ERROR 

is  raised  if  the  pathname  specified  by  NAME  is  syntaelif  lly  illegal  or  if  any 
traversed  node  In  the  path  specified  by  name  is  unobtainable  inaccessible  or  non¬ 
existent  or  if  the  relationship  specified  by  RELATION  and  KEY  or  by  the  last  path 
element  of  NAME  does  not  exist.  NAME_ERROR  is  also  raised  if  the  node  to 
which  a  handle  Is  to  be  opened  is  Inaccessible  or  unobtainable  and  the  given 
INTENT  Includes  any  intent  other  than  EXISTENCE. 

USE  _  ERROR  Is  raised  If  the  specified  INTENT  is  an  empty  array. 
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STATUS _ ERROR 

Is  raised  if  the  node  handle  NODE  Is  already  open  prior  to  the  call  on  OPEN  or  if 
BASE  is  not  an  open  node  handle. 

LOCK  _  ERROR 

is  raised  if  the  OPEN  operation  is  delayed  beyond  the  specified  time  limit  due  to 
the  existence  of  locks  in  conflict  with  the  specified  INTENT.  This  includes  any 
delays  caused  by  locks  on  nodes  traversed  on  the  path  specified  by  the  pathname 
NAME  or  locks  on  the  node  identified  by  BASE,  preventing  the  reading  of 
relationships  emanating  from  these  nodes. 

INTENT_  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  Intent  establishing  the  right  to  read 
relationships. 

ACCESS  _  VIOLATION 

Is  raised  if  the  current  process’  discretionary  access  control  rights  are  insufficient  to 
traverse  the  path  specified  by  NAME  by  BASE,  KEY  and  RELATION  or  to  obtain 
access  to  the  node  consistent  with  the  specified  INTENT.  ACCESS__  VIOLATION 
is  raised  only  if  the  conditions  for  NAME_ ERROR  are  not  present. 

SECURITY  _  VIOLATION 

Is  raised  if  the  attempt  to  obtain  access  to  the  node  with  the  specified  INTENT 
represents  a  violation  of  mandatory  access  controls  for  the  CAJS. 
SECURITY__ VIOLATION  is  raised  only  If  the  conditions  Tor  other  exceptions  are 
not  present. 


Notes: 

An  open  node  handle  acts  as  if  the  handle  forms  an  unnamed  temporary  secondary  relationship 
to  the  node;  this  means  that,  if  the  node  Identified  by  the  open  node  handle  is  renamed 
(potentially  by  another  process),  the  open  node  handle  tracks  the  renamed  node. 

It  Is  possible  to  open  a  node  handle  to  an  unobtainable  node  or  to  an  Inaccessible  node.  The 
latter  Is  consistent  with  the  fact  that  the  existence  of  a  relationship  emanating  from  an 
accessible  node  to  which  the  user  has  READ_ RELATIONSHIPS  rights  cannot  be  hidden  from 
the  user. 

5, 1.2.2.  Cloalng  a  node  handle 

procedure  close  (node  :  in  out  node_type>; 


Purpose: 

This  procedure  severs  any  association  between  the  node  handle  NODE  and  the  node  and  releases 
any  associated  lock  on  the  node  Imposed  by  the  intent  of  the  node  handle  NODE.  Closing  an 
already  closed  node  handle  has  no  effect. 

Parameter: 

NODE  is  a  node  handle,  initially  open,  to  be  closed. 


Exceptions: 
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none 

Notes: 

A  NODE_TYPE  variable  must  be  closed  before  another  OPEN  can  be  called  using  the  same 
NODE_TYT’E  variable  as  an  actual  parameter  to  the  formal  NODE  parameter  or  OPEN. 

5. 1.2.3.  Changing  the  intention  regarding  node  handle  usage 
procedure  chance  intcntcnode:  in  out  nqde  typE; 

INTENT:  in  INTENTION: 

TIME_LIMIT:  in  DURATION : = 

NO  DELAY); 


Purpose: 

This  procedure  changes  the  Intention  regarding  use  of  the  node  handle  NODE.  It  is  semantically 
equivalent  to  closing  the  node  handle  and  reopening  the  node  handle  to  the  same  node  with  the 
INTENT  and  TIME_LIMIT  parameters  or  CHANGE_  INTENT,  except  that 
CHANGE_  INTENT  guarantees  to  return  an  open  node  handle  that  refers  to  the  same  node  as 
the  node  handle  input  In  NODE  (see  the  Issue  explained  in  the  note  below). 

Parameter: 

NODE  is  an  open  node  handle 

INTENT  is  the  intent  of  subsequent  operations  on  the  node;  the  actual  parameter  takes  the 

form  of  an  array  aggregate. 

TIME  _  LIMIT  is  a  value  of  type  DURATION,  specifying  a  time  limit  for  the  delay  on  vaiting  for 
the  unlocking  of  a  node  in  accordance  w  ilh  the  desired  INTENT. 


Exceptions: 

NAME  _  ERROR 

is  raised  If  the  node  handle  NODE  refers  to  an  unobtainable  node  and  INTENT 
contains  any  Intent  specification  other  than  EXISTENCE. 

STATUS _ ERROR 

Is  raised  if  the  node  handle  NODE  is  not  an  open  node  handle. 

LOCK  _  ERROR 

Is  raised  if  the  operation  Is  delayed  beyond  the  specified  time  limit  due  to  the 
existence  of  locks  on  the  node  in  conflict  with  the  specified  INTENT. 

ACCESS  _  VIOLATION 

Is  raised  If  the  current  process'  discretionary  access  control  rights  are  Insufficient  to 
obtain  access  to  the  node  consistent  with  the  specified  INTENT. 
ACCESS_ VIOLATION  is  raised  only  If  the  condition  for  NAME_ERROR  is  not 
present. 

SECURITY  _  VIOLATION 

Is  raised  If  the  attempt  to  obtain  access  consistent  with  the  Intention  INTENT  to 
the  node  specified  by  NODE  represents  a  violation  of  mandatory  access  controls  for 
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the  CAIS.  SRCUrtlTY_ VIOLATION  is  raised  only  if  the  conditions  Tor  other 
exceptions  are  not  present. 


Notes: 

Use  of  the  sequence  of  a  CLOSE  and  an  OPEN  operation  instead  of  a  CHANGE _  INTENT 
operation  cannot  guarantee  that  the  same  node  is  opened,  since  relationships,  and  therefore  the 
node  identification,  may  have  changed  since  the  previous  OPEN  on  the  node. 

5. 1.2.4.  Examining  the  open  status  of  a  node  handle 

function  is_open(node:  in  node  type) 
return  boolean: 

Purpose: 

This  function  returns  TRUE  if  the  node  handle  NODE  is  open;  otherwise,  it  returns  FALSE. 
Parameter: 

NODE  is  a  node  handle. 


Exceptions: 

None. 


5.I.2.5.  Querying  the  intention  of  a  node  handle 

function  INTENT_OF<NOOE:  in  NODE  TYPE) 
return  INTENTION; 


Purpose: 

This  function  returns  the  intent  with  which  the  node  handle  NODE  Is  open. 

Parameter: 

NODE  is  an  open  node  handle. 

Exception: 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  Is  not  open. 

5. 1.2.0.  Querying  the  kind  of  a  node 

function  KIND  (NODE:  in  NODE  TYPE) 

return  node  kind” 

Purpose: 

This  function  returns  the  kind  of  a  node,  either  FILE,  PROCESS  or  STRUCTURAL. 

Parameter: 

NODE  Is  an  open  node  handle 
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Exceptions: 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  is  not  open. 

S. 1.2.7.  Obtaining  the  unique  primary  pathname 
function  prihary_name(node:  in  node  type) 

return-NANE_STPING ; 

Purpose: 

This  function  returns  the  unique  primary  name  of  the  node  identified  by  NODE. 
Parameter: 

NODE  Is  an  open  node  handle  Identifying  the  node. 


Exceptions: 

NAME  _  ERROR 

is  raised  If  any  node  traversed  on  the  primary  path  to  the  node  is  inaccessible. 
STATUS _ ERROR 

is  raised  If  the  node  handle  NODE  is  not  open. 

LOCK  _  ERROR 

Is  raised  If  access  consistent  with  intent  READ _  RELATIONSHIPS  to  any  node 
traversed  on  the  primary  path  cannot  be  obtained  due  to  an  existing  lock  on  the 
node. 

INTENT  _  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
relationships. 

ACCESS  _  VIOLATION 

Is  raised  If  the  current  process’  discretionary  access  control  rights  are  Insufficient  to 
traverse  the  node’s  primary  path.  ACCESS _ VIOLATION  Is  raised  only  If  the 
conditions  for  NAME_ERROR  are  not  present. 

5.I.2.8.  Obtaining  the  relationship  key  of  a  primary  relationship 

function  primary jcey (node:  in  node  type) 
return~RELATIONSHiP  key” 


Purpose: 

This  function  returns  the  relationship  key  of  the  last  path  element  of  the  unique  primary 
pathname  of  the  node. 

Parameter: 

NODE  Is  an  open  node  handle  identifying  the  node. 


Exceptions: 
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NAME_  ERROR 

Is  raised  if  the  parent  node  of  the  node  identified  by  NODE  is  Inaccessible. 

STATUS _ ERROR 

Is  raised  if  the  node  handle  NODE  is  not  open. 

LOCK  _ERROR 

is  raised  If  the  parent  node  is  locked  against  reading  relationships. 

INTENT_  VIOLATION 

Is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  relationships. 

ACCESS  _  VIOLATION 

Is  raised  if  the  current  process’  discretionary  access  control  rights  are  insufficient  to 
obtain  access  to  the  node's  parent  consistent  with  intent  READ_ RELATIONSHIP. 
ACCESS _ VIOLATION  Is  raised  only  ir  the  conditions  tor  NAME _ ERROR  are 
not  present. 

5. 1.2.0.  Obtaining  the  relation  name  of  a  primary  relationahip 

function  primary_relation(node:  in  NODEJIYPE) 
return  relation  name; 


Purpose: 

This  function  returns  the  relation  name  of  the  last  path  element  of  the  unique  primary 
pathname  of  the  node. 

Parameter: 

NODE  is  an  open  node  handle  Identifying  the  node. 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  parent  node  of  the  node  Identified  by  NODE  Is  Inaccessible. 

STATUS  _  ERROR 

Is  raised  If  the  node  handle  NODE  Is  not  open. 

LOCK _ ERROR 

Is  raised  if  the  parent  node  Is  locked  against  reading  relationships. 

INTENT  _  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
relationships. 

ACCESS  _  VIOLATION 

is  raised  if  the  current  process'  discretionary  access  control  rights  are  insufficient  to 
obtain  access  to  the  node's  parent  consistent  with  intent  to 
READ_RELATIONSIIIPS.  ACCESS_ VIOLATION  is  raised  only  if  the  conditions 
for  NAME_ERROR  are  not  present. 
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S. 1.2. 10.  Obtaining  the  relationship  key  of  t  e  last  relationship  traversed 
function  path_key(node;  in  node_type) 

return  RELATIONSHIP  KEY; 


Purpose; 

This  function  returns  the  relationship  key  of  the  r<  latlonshlp  corresponding  to  the  last  path 
element  of  the  pathname  used  In  opening  this  node  I  mdle.  Since  a  path  element  is  a  string,  the 
relationship  key  Is  returned  even  if  the  relationship  It  *  been  deleted. 

Parameter: 

NODE  is  an  open  node  handle. 

Exceptions: 

STATUS _ ERROR 

Is  raised  if  the  node  handle  NODE  is  n  t,  open. 

5.1.2.11.  Obtaining  the  relation  name  of  the  last  relationship  traversed 

function  path_relation(node.-  in  nodejtype) 
return  relationname; 


Purpose: 

This  function  returns  the  relation  name  of  the  r<  ulonshlp  corresponding  to  the  last  path 
element  of  the  pathname  used  in  opening  this  node  It  ndle.  The  relation  name  is  returned  even  ir 
the  relationship  has  been  deleted. 

Parameter: 

NODE  Is  an  open  node  handle. 

Exceptions: 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  is  t.  open. 

5.1.2.12.  Obtaining  a  partial  pathname 

function  base_path  (name  :  in  name  string) 
return  name  string; 


Purpose: 

This  function  returns  the  pathname  obtained  by  d<  i  Ung  the  last  path  element  from  NAME.  It 
does  not  establish  whether  the  pathname  id  end  •»  an  existing  node;  only  the  syntactic 
properties  of  the  pathname  are  examined.  This  fun 'lion  also  checks  the  syntactic  legality  of  the 
pathname  NAME. 

Parameters: 

NAME  Is  a  pathname  (not  necessarily  Identifying  a  node). 
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Exceptions: 

NAME  _  ERROR 

Is  raised  If  NAME  Is  a  syntactically  Illegal  pathname. 

5.1.2.13.  Obtaining  the  name  of  the  last  relationship  in  a  pathname 

function  last_relation  (hake  :  in  name_string) 
return  relation  name; 


Purpose: 

This  function  returns  the  name  of  the  relation  of  the  last  path  element  of  the  pathname  NAME. 
It  does  not  establish  whether  the  pathname  Identifies  an  existing  node;  only  the  syntactic 
properties  of  the  pathname  are  examined.  This  function  also  checks  the  syntactic  legality  of  the 
pathname  NAME. 

Parameters: 

NAME  Is  a  pathname  {not  necessarily  Identifying  a  node). 


Exceptions: 

NAME_  ERROR 

Is  raised  if  NAME  Is  a  syntactically  illegal  pathname. 

5.1.2.14.  Obtaining  the  key  of  the  laat  relationship  in  a  pathname 

function  LASTKEY  (NAME :  in  KAMESTRING) 
return  relationship  KEY; 


Purpose: 

This  function  returns  the  relationship  key  of  the  last  path  element  of  the  pathname  NAME.  It 
does  not  establish  whether  the  pathname  identifies  an  existing  node;  only  the  syntactic 
properties  of  the  pathname  are  examined.  This  function  checks  the  syntactic  legality  of  the 
pathname  NAME. 

Parameters: 

NAME  Is  a  pathname  (not  necessarily  Identifying  a  node). 


Exceptions: 

NAME_  ERROR 

Is  raised  If  NAME  Is  a  syntactically  illegal  pathname. 

5.1.2.15.  Querying  the  existence  of  a  node 

function  is_obtainable(node:  in  node_type) 
return  boolean: 


Purpose: 


This  function  returns  FALSE  if  the  node  Identified  by  NODE  Is  unobtainable  or  inaccessible.  It 
returns  TRUE  otherwise. 
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Parameters: 

NODE  is  an  open  node  handle  identifying  the  node. 


Exceptions: 

STATUS _ ERROR 

is  raised  if  NODE  Is  not  an  open  node  handle. 


Additional  Interfaces: 

function  is_obtainable  (name  :  in  name_string) 
return  boolean 

is 

NODE:  NODE_TYPE ; 

RESULT:  BOOLEAN; 
begin 

OPEN (NODE ,  NAME.  (1=>EXISTENCE) ) ; 

RESULT  :  =  ISOBTAINABLE (NODE) ; 

CLOSE (NODE) ;“ 

return  result; 
exception 

when  others  =>  return  false; 
end  IS  OBTAINABLE; 

function  is  obtaikable (base :  in  node  type; 

KEY:  in  RELATT0NSHIP_KEY; 

RELATION:  in  R£LATION_NAME  :=  DEFAULT_RELATION) 

return  boolean 

is 

NODE:  NODETYPE; 

RESULT:  BOOLEAN; 
begin 

OPEN (NODE.  BASE.  KEY.  RELATION.  ( 1 =>EXISTENCE) ) ; 

RESULT  :=  ISOBTAINABLE (NODE) ; 

CLOSE (NODE); 
return  result; 
exception 

when  others  =>  return  false; 
end  is  obtainable: 


Notes: 

OBTAINABLE  can  be  used  to  determine  whether  a  node  identified  via  a  secondary  relationship 
has  been  made  unobtainable  by  a  DELETE  operation  or  is  inaccessible  to  the  current  process 
(see  Note  In  Section  5. 1.2. 3). 


5.1.2.10.  Querying  sameness 

function  is_same (node;  :  in  node_type; 

N0DE2:  in  N0DE_TYPE) 
return  boolean; 

Purpose: 

This  function  returns  TRUE  If  the  node>  Identified  by  its  arguments  are  the  same  node; 
otherwise.  It  returns  FALSE. 

Parameters: 

NODE  I  Is  an  open  node  handle  to  a  node. 
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NODE2  Is  an  open  node  handle  to  a  node. 


Exceptions: 

ST  \TUS_ ERROR 

Is  raised  if  at  least  one  of  the  node  handles,  NODEl  and  NODE2,  is  not  open. 


Additional  Interface: 

function  is_same(namei :  in  name  string; 

NAME2 :  in  NAMESTRING) 

return  boolean 

ie 

NODEl,  N0DE2:  NODETYPE: 

RESULT:  BOOLEAN; 

begin 

OPEN (NODEl ,  NAME1 ,  (1=>EXISTENCE) ) ; 

begin 

OPEN (N0DE2 ,  NAME2,  (1=>EXISTENCE) ) ; 
exception 

when  others  => 

CLOSE (NODEl) ; 

raise; 

end; 

RESULT  :  =  IS  SAME (NODEl,  N0DE2) ; 

CLOSE (NODEl) 7 
CLOSE (N0DE2) ; 
return  RESULT; 
end  is  same: 

Notes: 

Sameness  Is  not  to  be  confused  with  equality  of  attribute  values,  relationships  and  contents  of 
nodes,  which  is  a  necessary  but  not  a  sufficient  criterion  for  sameness. 


5.1.2.17.  Obtaining  an  open  node  handle  to  the  parent  node 


procedure  get  parent  (parent  . 

NODE: 

INTENT: 

TIME  LIMIT: 


in  out  NQDE_TYPE: 
in  NODE_TYPE; 

in  INTENTION  :=  (1=>READ) ; 

in  DURATION  :  =  NO  DELAY); 


Purpose: 

This  procedure  returns  an  open  node  handle  in  PARENT  to  the  parent  node  of  the  node 
identified  by  the  open  node  handle  NODE.  The  Intent  under  which  the  node  handle  PARENT  is 
opened  Is  specified  by  INTENT.  A  call  on  GET _  PARENT  is  equivalent  to  a  call 
OPEN(PARENT,  NODE,  PARENT,  INTENT,  TIME _ LIMIT). 

Parameters: 

PARENT  Is  a  node  handle.  Initially  closed,  to  be  opened  to  the  parent  node. 

NODE  is  an  open  node  handle  Identifying  the  node. 

INTENT  is  the  intent  of  subsequent  operations  on  the  node  handle  PARENT. 


TIME_ LIMIT  Is  a  value  of  type  DURATION,  specifying  a  lime  limit  for  the  delay  on  waiting  for 
the  unlocking  of  the  parent  node  in  accordance  with  the  desired  INTENT. 
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Exceptions: 

NAME_  ERROR 

is  raised  if  the  node  identified  hy  NODE  Is  a  top-level  node  or  if  its  parent  node  is 
Inaccessible. 

USE  _  ERROR  is  raised  if  the  specified  INTENT  Is  an  empty  array. 

STATUS _ ERROR 

is  raised  If  the  node  handle  PARENT  is  open  prior  to  the  call  or  If  the  node  handle 
NODE  Is  not  open. 

LO<’K_  ERROR 

Is  raised  If  the  opening  of  the  parent  node  is  delayed  beyond  the  specified 
T1ME_ LIMIT  due  to  the  existence  of  locks  in  conflict  with  the  specified  INTENT. 

INTENT  _  VIOLATION 

Is  raised  If  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
relationships. 

ACCESS  _  VIOLATION 

is  raised  If  the  current  process’  discretionary  access  control  rights  are  insufficient  to 
obtain  access  to  the  parent  node  with  the  specified  INTENT. 
ACCESS _ VIOLATION  is  raised  only  If  the  conditions  for  NAME_ERROR  are 
not  present. 

SECURITY^  VIOLATION 

is  raised  If  the  attempt  to  gain  with  the  specified  INTENT  access  to  the  parent 
node  represents  a  violation  of  mandatory  access  controls  for  the  CA1S. 
SECURITY _ VIOLATION  is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 


5.1.2.18.  Copying  a  node 


procedure  copynode  (from  : 

TO_BASE: 

TOJCEY: 

T0"RELATI0N: 


in  NODE  TYPE; 
in  MODE” TYPE; 
in  RELATIONSHIPKEY; 
in  RELATION  NAME 


:=DEFAULT  RELATION); 


Purpose: 


This  procedure  copies  a  file  or  structural  node  that  does  not  have  emanating  primary 
relationships.  The  node  copied  Is  Identified  by  the  open  node  handle  FROM  and  is  copied  to  a 
newly  created  node.  The  new  node  is  identified  by  the  combination  of  the  TO  _  BASE, 
TO _ KEY  and  TO  _ RELATION  parameters.  The  newly  created  node  is  of  the  same  kind  as  the 
node  Identified  by  FROM.  If  the  node  Is  a  file  node.  Its  contents  are  also  copied,  i.e.,  a  new 
copied  file  Is  created.  Any  secondary  relationships  emanating  from  the  original  node,  excepting 
the  relationship  of  the  predefined  relation  PARENT  (which  Is  appropriately  adjusted),  are 
recreated  In  the  copy.  If  the  target  of  the  original  node’s  relationship  Is  the  node  itself,  then  the 
copy  has  an  analogous  relationship  to  Itself.  Any  other  secondary  relationship  whose  target  Is 
the  original  node  is  unaffected.  All  attributes  of  the  FROM  node  are  also  copied.  Regardless  of 
any  locks  on  the  node  Identified  by  FROM,  the  newly  created  node  Is  unlocked. 


Parameters: 
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FROM  Is  an  open  node  handle  to  the  node  to  be  copied. 

TO  _ BASE  Is  an  open  node  handle  to  the  base  node  for  Identification  of  the  node  to  be  created. 

TO_KEY  is  a  relationship  key  for  the  Identification  of  the  node  to  be  created. 

TO  _  RELATION 

is  a  relation  name  for  the  Identification  of  the  node  to  be  created. 


Exceptions: 

NAME  _  ERROR 

is  raised  If  the  new  node  Identification  Is  Illegal  or  ir  a  node  already  exists  with  the 
Identification  given  for  the  new  node. 

USE_ ERROR  is  raised  If  the  original  node  Is  not  a  file  or  structural  node  or  ir  any  primary 
relationships  emanate  from  the  original  node.  USE_ ERROR  is  also  raised  if 
TO _  RELATION  Is  the  name  of  a  predefined  relation  that  cannot  be  modified  or 
created  by  the  user. 

STATUS _ ERROR 

Is  raised  ir  the  node  handles  FROM  and  TO _ BASE  are  not  both  open. 

INTENT  _  VIOLATION 

Is  raised  If  FROM  was  not  opened  with  an  Intent  establishing  the  right  to  read 
contents,  attributes,  and  relationships  or  ir  TO _  BASE  was  not  opened  with  an 
Intent  establishing  the  right  to  append  relationships.  INTENT  _ VIOLATION  is  not 
raised  If  the  conditions  for  NAME _ ERROR  are  present. 

SECURITY  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls  and  the 
conditions  for  other  exceptions  are  not  present. 


Additional  Interface: 

procedure  copy_node  (from  :  in  node_type; 

TO :  in  NA«E~  STRING) 

is 

TOBASE:  NODETYPE: 
begin 

OPEN (TO_BASE .  BASE_PATH(TO) .  (1=>APPEND  RELATIONSHIPS)) ; 
COPYNODE (FROM ,  TO~BASE.  LAST  KEY (TO) ,  LAST  RELATION (TO) ) ; 
CLOSE (TO_BASE) ; 
exception 

when  others  => 

CLOSE (TO_BASE) ; 
raise; 
end  COPY  NODE; 
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5.1.2.19.  Copying  trees 


procedure  COPY_TR£E  (FROM : 

TO_BASE: 
TO~KEY : 

TO  RELATION: 


in  NODE  TYPE; 
in  NOOE~ TYPE; 
in  RELATIONSHIP  KEY; 
in  RELATION  NAMi 
: =DEFAULT_RELATION) ; 


Purpose: 


This  procedure  copies  a  tree  of  file  or  structural  nodes  formed  by  primary  relationships 
emanating  from  the  node  identified  by  the  open  node  handle  FROM.  Primary  relationships  are 
recreated  between  corresponding  copied  nodes.  The  root  node  of  the  newly  created  tree 
corresponding  to  the  FROM  node  Is  the  node  identified  by  the  combination  of  the  TO  _ BASE, 
TO_KEY  and  TO_RELATlON  parameters,  if  an  exception  Is  raised  by  the  procedure,  none  of 
the  nodes  are  copied.  Secondary  relationships,  attributes,  and  node  contents  are  copied  as 
described  for  COPY _  NODE  with  the  following  additional  rules:  secondary  relationships 
between  two  nodes  which  both  are  copied  are  recreated  between  the  two  copies.  Secondary 
relationships  emanating  from  a  node  which  is  copied,  but  which  refer  to  nodes  outside  the  tree 
being  copied,  are  copied  so  that  they  emanate  from  the  copy,  but  still  refer  to  the  original  target 
node.  Secondary  relationships  emanating  from  a  node  which  Is  not  copied,  but  which  refer  to 
nodes  inside  the  tree  being  copied,  are  unaffected.  If  the  node  identified  by  TO  _  BASE  is  part 
of  the  tree  to  be  copied,  then  the  copy  of  the  node  Identified  by  FROM  will  not  be  copied 
recursively. 


Parameters: 

FROM 

TO  _  BASE 

TO  KEY 


Is  an  open  node  handle  to  the  root  node  of  the  tree  to  be  copied. 

is  an  open  node  handle  to  the  base  node  for  Identification  of  the  node  to  be  created 
as  root  of  the  new  tree. 

is  a  relationship  key  Tor  the  Identification  of  the  node  to  be  created  as  root  of  the 
new  tree. 


TO  _  RELATION 

Is  a  relation  name  for  the  identification  of  the  node  to  be  created  as  root  of  the  new 
tree. 


Exceptions: 

NAME_ ERROR 

Is  raised  if  the  new  node  Identification  Is  illegal  or  if  a  node  already  exists  with  the 
identification  given  for  the  new  node  to  be  created  as  a  copy  of  the  node  identified 
by  FROM. 

STATUS _ ERROR 

is  raised  If  the  node  handles  FROM  and  TO _  BASE  are  not  both  open. 

USE_ ERROR  is  raised  if  the  original  node  is  not  a  file  or  structural  node.  IJSE_ ERROR  is  also 
raised  if  TO _ RELATION  is  the  name  of  a  predefined  relation  that  cannot  be 
modified  or  created  by  the  user. 

LOCK  _  ERROR 

is  raised  if  any  node  to  be  copied  except  the  node  identified  by  FROM,  is  locked 
against  read  access  to  attributes,  relationships  or  contents. 
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INTENT_  VIOLATION 

is  raised  if  FROM  is  not  <  i  n  with  an  intent  establishing  the  right  to  read  node 
contents,  attributes  and  rrla  ionships  or  if  TO _ BASE  is  not  open  with  an  intent 
establishing  the  right  to  t|  pend  relationships.  INTENT_ VIOLATION  is  only 
raised  if  the  conditions  for  N\ME_ERROR  are  not  present. 

ACCESS  _  VIOLATION 

is  raised  if  the  current  process'  discretionary  access  control  rights  are  Insufficient  to 
obtain  access  to  each  node  to  be  copied  with  intent  READ. 
ACCESS_ VIOLATION  Is  not  raised  if  conditions  for  NAME_ERROR  are  present. 

SECURITY_  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls  and  the 
conditions  for  other  exceptions  are  not  present. 


Additional  Interface: 

procedure  copy_tree (from :  in  node  TYPE; 

TO:  in  name” STRING) 

is 

TOBASE :  NODETYPE; 
begin 

OPENOO  BASE,  BASEPATH(TO) .  (1=>APPEND_RELATI0NSHIPS) ) ; 
COPY  TREE (FROM.  TO~BASE,  LAST  KEY (TO) .  LASTRELAT ION (TO) ) : 
CLOSE (TOBASE) ; 
exception 

when  others  => 

CLOSE (TOBASE) ; 

raise: 

end  copy  tree; 


5.1.2.20.  Renaming  the  primary  relationship  of  a  node 


Purpose: 


procedure  rename  (node:  in  node  type; 

NEW  BASE :  in  N0DE~TYPE ; 

NEWJCEY:  in  RELATIONSHIPKEY; 

NEW~RELATION :  in  RELATIONNAME 

: =DEFAULT  RELATION) ; 


This  procedure  renames  a  file  or  structural  node.  It  deletes  the  primary  relationship  to  the  node 
identified  by  NODE  and  Installs  a  new  primary  relationship  to  the  node,  emanating  from  the 
node  identified  by  NEW_BASE,  with  key  and  relation  name  given  by  the  NEW_KEY  and 
NEW _ RELATION  parameters.  The  parent  relationship  is  changed  accordingly.  This  changes 
the  unique  primary  pathname  of  the  node.  Existing  secondary  relationships  with  the  renamed 
node  as  target  track  the  renaming,  i.e.,  they  have  the  renamed  node  as  target. 


Parameters: 

NODE  is  an  open  node  handle  to  the  node  to  be  renamed. 

NEW _ BASE  Is  an  open  node  handle  to  the  base  node  Trom  which  the  new  primary  relationship  to 
the  renamed  node  emanates. 

NEW _  KEY  is  a  relationship  key  for  the  new  primary  relationship. 
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NEW  _  RELATION 

is  a  relation  name  for  the  new  primary  relationship. 


Exceptions: 

NAME  _  ERROR 

is  raised  If  the  new  node  Identification  is  Illegal  or  if  a  node  already  exists  with  the 
identification  given  for  the  new  node. 

USE_ ERROR  is  raised  If  the  node  identified  by  NODE  Is  not  a  file  or  structural  node  or  If  the 
renaming  cannot  be  accomplished  while  still  maintaining  acircularity  of  primary 
relationships  (e.g.,  If  the  new  parent  node  would  be  the  renamed  node). 
USE_  ERROR  Is  also  raised  if  NEW  _  RELATION  is  the  name  of  a  predefined 
relation  that  cannot  be  modified  or  created  by  the  user  or  if  the  primary 
relationship  to  be  deleted  belongs  to  a  predefined  relation  that  cannot  be  modified 
by  the  user. 

STATUS _ ERROR 

Is  raised  if  the  node  handles  NODE  and  NEW  _  BASE  are  not  open. 

LOCK  _  ERROR 

is  raised  if  access,  with  Intent  WRITE_ RELATIONSHIPS,  to  the  parent  of  the 
node  to  be  deleted  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

INTENT  _  VIOLATION 

is  raised  If  NODE  was  not  opened  with  an  Intent  establishing  the  right  to  write 
relationships  or  if  NEW_BASE  was  not  opened  with  an  Intent  establishing  the 
right  to  append  relationships. 

ACCESS  _  VIOLATION 

is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  the  parent  of  the  node  to  be  renamed  with  intent 
WRITE _ RELATIONSHIPS  and  the  conditions  Tor  NAME _  ERROR  are  not 
present. 

SECURITY_  VIOLATION 

is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY _ VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  rename  (MODE  :  in  node  type; 

NEWNAME:  in  NAMESTRING) 

is 

NEW_BASE:  NODEJTYPE ; 

begin 

OPEN (NEW_BASE ,  BASE_PATH(NEW_NAME) ,  (1 =>APPEND  RELATIONSHIPS) ) ; 
RENAME  (NODE.  NEN_BASE,  LAST~KEY (NEW_NAME) . 

LAST_RELATION (NEW_NAME) ) ; 

CLOSE (NEN_BASE) ; 
exception 

when  others  => 

CLOSE (MEWBASE) ; 
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raise; 

end  RENAN17.; 

Notes; 

Open  node  handles  from  existing  processes  track  the  renamed  node. 


5.1.2.21.  Deleting  the  primary  relationship  to  a  node 

procedure  delete  node  (node;  in  out  node_type)  ; 


Purpose: 

This  procedure  deletes  the  primary  relationship  to  a  node  identified  by  NODE.  The  node 
becomes  unobtainable.  The  node  handle  NODE  is  closed.  If  the  node  is  a  process  node  and  the 
process  Is  not  yet  TERMINATED  (see  Section  5.2),  DELETE_NODE  aborts  the  process. 

Parameters: 

NODE  is  an  open  node  handle  to  the  node  which  is  the  target  of  the  primary  relationship 

to  be  deleted. 


Exceptions: 

NAME  _  ERROR 

is  raised  if  the  parent  node  of  the  node  Identified  by  NODE  is  inaccessible. 
USE_ERROR  Is  raised  if  any  primary  relationships  emanate  from  the  node. 

STATUS  _  ERROR 

is  raised  if  the  node  handle  NODE  is  not  open  prior  to  the  call. 

LOCK  _  ERROR 

Is  raised  if  access,  with  Intent  WRITE_RELATIONSHIPS,  to  the  parent  of  the 
node  to  be  deleted  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

INTENT_  VIOLATION 

is  raised  If  the  node  handle  NODE  was  not  opened  with  an  Intent  including 
EXCLUSIVE _  WRITE  and  READ  _  RELATIONSHIPS. 

ACCESS  _  VIOLATION 

Is  raised  If  the  current  process  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  the  parent  of  the  node  to  be  deleted  with  intent 
WRITE _  RELATIONSHIPS  and  the  conditions  for  NAME _ ERROR  are  not 
present. 

SECURITY  _  VIOLATION 

Is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_ VIOLATION  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  delete  node  (name  :  in  nanestring) 

is 
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MODE:  NODE_TYPE; 
begin 

OPEN (MODE,  NAME,  (EXCLUSIVE  JffilTE, READ_R£LATIONSHIPS) ) ; 
DELETE_NODE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  DELETE  NODE; 


Notes; 

The  DELETE _  NODE  operations  cannot  be  used  to  delete  more  than  one  primary  relation  node 
In  a  single  operation.  It  Is  left  to  an  Implementation  decision  whether  and  when  nodes  whose 
primary  relationships  have  been  broken  are  actually  removed.  However,  secondary  relationships 
to  such  nodes  must  remain  until  they  are  explicitly  deleted  using  the  UNLINK  procedures. 


5.1.2.22.  Deleting  the  primary  relationships  of  a  tree 
procedure  delete  tree  (node  :  in  out  node_type)  ; 


Purpose: 

This  procedure  effectively  performs  the  DELETE_NODE  operation  for  a  specified  node  and 
recursively  applies  DELETE_TREE  to  all  nodes  reachable  by  a  unique  primary  pathname  from 
the  designated  node.  The  nodes  whose  primary  relationships  are  to  be  deleted  are  opened  with 
intent  EXCLUSIVE  _  WRITE,  thus  locking  them  for  other  operations.  The  order  In  which  the 
deletions  of  primary  relationships  is  performed  Is  not  specified.  If  the  DELETE_TREE 
operation  raises  an  exception,  none  of  the  primary  relationships  is  deleted. 

Parameters: 

NODE  is  an  open  node  handle  to  the  node  at  the  root  of  the  tree  whose  primary 

relationships  are  to  be  deleted. 


Exceptions: 

NAME  _  ERROR 

Is  raised  if  the  parent  node  of  the  node  Identified  by  NODE  or  any  of  the  target 
nodes  of  primary  relationships  to  be  deleted  are  inaccessible. 

USE_ERROR  is  raised  if  the  primary  relationship  to  the  node  Identified  by  NODE  belongs  to  a 
predefined  relation  that  cannot  be  modified  by  the  user. 

STATUS _ ERROR 

Is  raised  If  the  node  handle  NODE  Is  not  open  prior  to  the  call. 

LOCK  _  ERROR 

is  raised  if  a  node  handle  to  the  parent  of  the  node  specified  by  NODE  cannot  be 
opened  with  Intent  WRITE_ RELATIONSHIPS  or  If  a  node  handle  Identifying  any 
node  whose  unique  primary  path  traverses  the  node  identified  by  NODE  cannot  be 
opened  with  intent  EXCLUSIVE _  WRITE. 

INTENT  _  VIOLATION 

Is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  including 
EXCLUSIVE _  WRITE  and  READ _  RELATIONSHIPS. 
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ACCESS_  VIOLATION 

is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  the  parent  of  the  node  specified  by  NODE  with  intent 
WRITE_ RELATIONSHIPS  or  to  obtain  access  to  any  target  node  of  a  primary 
relationship  to  be  deleted  with  Intent  EXCLUSIVE_ WRITE  and  the  conditions  for 
NAME  _  ERROR  are  not  present. 

SEClfRITY_  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_ VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

Additional  Interface: 

procedure  delete  tree  (name  :  in  name_string) 

is 

NODE:  NODE  TYPE; 
begin 

OPEN (NODE.  NAME.  (EXCLUSIVE  WRITE ,READ_RELATIONSHIPS) ) ; 

DELETEJTREE (NODE) ; 
exception- 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  DELETE  TREE; 


Notes: 

This  operation  can  be  used  to  delete  more  than  one  primary  relationship  In  a  single  operation. 

5.1.2.23.  Creating  secondary  relationships 

procedure  link  (node:  in  NODEJYPE; 

NEWBASE:  in  NODEJTfPE; 

NEWJCEY:  in  RELATIONSHIP_KEY ; 

MEW ’relation :  in  RELATION_NAME 

:  =DEI'AULT_RELATIOW)  ; 

Purpose: 

This  procedure  creates  a  secondary  relationship  between  two  existing  nodes.  The  procedure 
takes  a  node  handle  NODE  on  the  target  node,  a  node  handle  NEW_BASE  on  the  source  node, 
and  an  explicit  key  NEW_KEY  and  relation  name  NEW_RELATION  for  the  relationship  to 
be  established  from  NEW  _  BASE  to  NODE. 

Parameters: 

NODE  is  an  open  node  handle  to  the  node  to  which  the  new  secondary  relationship  points. 

NEW _ BASE  Is  an  open  node  handle  to  the  base  node  from  which  the  new  secondary  relationship 
to  the  node  emanates. 

NEW_KEY  is  the  relationship  key  for  the  new  secondary  relationship. 

NEW  _  RELATION 

Is  the  relation  name  for  the  new  secondary  relationship. 


Exceptions: 
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NAME  _  ERROR 

is  raised  if  the  relationship  key  or  the  relation  name  are  illegal  or  if  a  node  already 
exists  with  the  identification  given  by  NEW  _  BASE,  NEW  _  KEY,  and 
NEW  _  RELATION. 

USE_ ERROR  Is  raised  if  NEW_RELATION  is  the  name  of  a  predefined  relation  that  cannot  be 
modified  or  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  the  node  handles  NODE  and  NEW _  BASE  are  not  open. 

INTENT  _  VIOLATION 

Is  raised  if  NEW  _  BASE  was  not  opened  with  an  intent  establishing  the  right  to 
append  relationships. 

SECUR1TY_  VIOLATION 

Is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY _  VIOLATION  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  link  (node:  in  nodetype; 

NEW  NAME:  in  NAME- STRING) 

is 

NEWBASE:  NODETYPE; 
begin 

OPEN (NEWBASE.  BASE  PATH ( NEWNAME) .  (1=>APPEND_RELATI0NSHIPS) ) ; 
LINK (NODE.  NEW  BASE?  LAST  KEY (NEW  NAME). 

LASTRELATIQN (NEWNAME) ) ; 

CLOSE (NEWBASE) ; 
exception 

when  other*  => 

CLOSE (NEWBASE) ; 

raise: 
end  link: 


5.1.2.24.  Deleting  secondary  relationships 

procedure  unlink  (BASE:  in  node_type: 

KEY:  in  RELATIONSHIP  JCEY; 

RELATION:  in  RELATION_NAME 

: =DEFAULT_RELATION) ; 

Purpose: 

This  procedure  deletes  a  secondary  relationship  Identified  by  the  BASE,  KEY  and  RELATION 
parameters. 


Parameters: 

BASE  is  an  open  node  handle  to  the  node  from  which  the  relationship  emanates  which  is 

to  be  deleted. 

KEY  Is  the  relationship  key  of  the  relationship  to  be  deleted. 
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RELATION  Is  the  relation  name  of  the  relationship  to  be  deleted. 

Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  relationship  Identified  by  BASE,  KEY  and  RELATION  does  not 
exist. 

USE_  ERROR  is  raised  if  the  specified  relationship  is  a  primary  relationship.  USE_  ERROR  is 
also  raised  If  RELATION  is  the  name  of  a  predefined  relation  that  cannot  be 
modified  or  created  by  the  user. 

STATUS _ ERROR 

Is  raised  if  the  BASE  is  not  an  open  node  handle. 

INTENT_  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  write 
relationships. 

SECURITY  _  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_  VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

Additional  Interface: 

procedure  unlink  (name  :  in  NAME  STRING) 

is 

BASE:  NODE  TYPE; 
begin 

OPEN (BASE .  BASE  PATH (NAME) .  (1=> WRITE  RELATIONSHIPS)); 

UNLINK (BASE ,  LAST  KEY (NAME) .  LAST  RELATION (NAME) ) ; 

CLOSE (BASE); 
exception 

when  others  => 

CLOSE (BASE) ; 
raise; 

end  unlink; 

Notes: 

UNLINK  can  be  used  to  delete  secondary  relationships  to  nodes  that  have  become  unobtainable. 

5.1.2.25.  Node  iteration  types  and  subtypes 

type  node_iterator  is  limited  private: 
subtype  relationship  key  pattern  is  relationship  key ; 
subtype  relation_namI_pattern  is  relationname; 

These  types  are  used  in  the  following  Interfaces  for  Iterating  over  a  set  or  nodes. 
RELATIONSHIP  _  KEY  _  PATTERN  and  RELATION _NAME_ PATTERN  follow  the  syntax  or 
relationship  keys  and  relation  names,  except  that  '?’  will  match  any  single  character  and  will  match 
any  siring  of  characters.  NODE_ITERATOR  Is  a  private  type  assumed  to  contain  the  bookkeeping 
Information  necessary  for  the  implementation  of  the  MORE  and  GET_NEXT  functions.  The  nodes 
are  returned  by  GET_NEXT  In  ASCII  lexicographical  order  by  relation  name  and  then  by 
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relationship  key.  The  effect  on  existing  Iterators  of  creation  or  deletion  of  relationships  is 
Implementation-defined. 


5.1.2.20.  Creating  an  iterator  over  nodes 


procedure  iterate  (iterator: 

NOPE: 

KIND: 

KEY: 

RELATION: 

PRIMARY_0NLY: 


out  NODE_ITERATOR; 
in  N0DE_TYPE; 
in  NODEJCIND; 

in  RELATIONSHIP_KEY_PATTERN 
in  RELATION  NAME  PATTERN 
=  DEFAULT_RELATION~ 
in  BOOLEAN  :=  TRUE): 


Purpose: 


*•*; 


This  procedure  establishes  a  node  Iterator  ITERATOR  over  the  set  of  nodes  that  are  the  targets 
of  relationships  emanating  from  a  given  node  identified  by  NODE  and  matching  the  specified 
KEY  and  RELATION  patterns.  Nodes  that  are  of  a  different  kind  than  the  KIND  specified  are 
omitted  by  subsequent  calls  to  GET_NEXT  using  the  resulting  ITERATOR.  If 
PRIMARY_  ONLY  Is  true,  then  the  Iterator  will  be  based  on  only  primary  relationships. 


Parameters: 

ITERATOR 

NODE 

KIND 

KEY 

RELATION 


Is  the  node  iterator  returned. 

Is  an  open  node  handle  to  a  node  whose  relationships  form  the  basis  for  constructing 
the  Iterator. 

is  the  kind  of  nodes  on  which  the  Iterator  is  based. 

Is  the  pattern  for  the  relationship  keys  on  which  the  Iterator  is  based, 
is  the  pattern  for  the  relation  names  on  which  the  Iterator  is  based. 


PRIMARY  _  ONLY 

Is  a  boolean;  If  TRUE,  the  Iterator  will  be  based  on  only  primary  relationships;  if 
FALSE.the  iterator  will  be  based  on  all  relationships  satisfying  the  patterns. 


Exceptions: 

USE_ERROR  is  raised  If  the  pattern  given  In  KEY  or  RELATION  Is  syntactically  illegal. 
STATUS _ ERROR 

is  raised  if  NODE  Is  not  an  open  node  handle. 


INTENT  _  VIOLATION 

Is  raised  If  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
relationships. 


Additional  Interface: 


procedure  iterate  (iterator: 


NAME: 

in 

KIND: 

in 

KEY: 

in 
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RELATION :  in  R£LATION_NAME_PATTERN 

DEFAULT_RELATION~ 
PRIMARY_ONLY :  in  BOOLEAN  :=  TRUE) 

ia 

NODE:  NODE_TYPE ; 
begin 

OPEN (NODE ,  NAME,  (1=>READ  RELATIONSHIPS) ) ; 

ITERATE (ITERATOR,  NODE,  KIND,  KEY,  RELATION.  PRIMARY_ONLY) ; 
CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE  (NODE) : 
raise; 

end  ITERATE; 


Notes: 

The  functions  PATH _ KEY  and  PATH  _ RELATION  may  be  used  to  determine  the  relationship 
which  caused  the  node  to  be  Included  In  the  Iteration.  The  iteration  interfaces  can  be  used  to 
determine  relationships  to  inaccessible  or  unobtainable  nodes. 


5.1.2.27.  Determining  iteration  status 


function  more  (iterator:  in  node_iterator> 
return  boolean  ; 


Purpose: 

The  function  MORE  returns  FALSE  If  all  nodes  contained  in  the  node  iterator  have  been 
retrieved  with  the  GET  _  NEXT  procedure;  otherwise  it  returns  TRUE. 

Parameters: 

ITERATOR  Is  a  node  Iterator  previously  set  by  the  procedure  ITERATE. 


Exceptions: 

USE_ERROR  is  raised  If  the  ITERATOR  has  not  been  previously  set  by  the  procedure  ITERATE. 


5.1.2.28.  Getting  the  next  node  in  an  iteration 


procedure  cetnext  (iterator  :  in  out 

nejct_node:  in  out 

INTENT :  in 

TIME  LIMIT:  in 


NODE_ITERATOR; 

NODE*  TYPE; 

INTENTION  :=  (1=>EXISTENCE) ; 
DURATION  : =  NO  DELAY) ; 


Purpose: 


The  procedure  GET _ NEXT  returns  an  open  node  handle  to  the  next  node  In  the  parameter 
NEXT__NODE;  the  Intent  under  which  the  node  handle  is  opened  is  specified  by  the  INTENT 
parameter.  If  NEXT _  NODE  is  open  prior  to  the  call  to  GET _  NEXT,  it  is  closed  prior  to  being 
opened  to  the  next  node.  A  lime  limit  can  be  specified  for  the  maximum  delay  permitted  if  the 
node  to  be  opened  is  locked  against  access  with  the  specified  INTENT. 


Parameters: 

ITERATOR  is  a  node  iterator  previously  set  by  ITERATE. 


NEXT  _  NODE 

is  a  node  handle  to  be  opened  to  the  next  node  on  the  ITERATOR. 
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INTENT  Is  the  Intent  of  subsequent  operations  on  the  node  handle  NEXT_NODE. 

TIME_LIMIT  is  a  value  of  type  DURATION,  specifying  a  time  limit  for  the  delay  on  waiting  for 
the  unlocking  of  the  node  In  accordance  with  the  desired  INTENT. 


Exceptions: 

NAME_  ERROR 

Is  raised  If  the  node  whose  node  handle  Is  to  be  returned  In  by  NEXT_NODE  Is 
unobtainable  and  If  the  INTENT  Includes  any  Intent  other  than  EXISTENCE. 

USE _  ERROR  Is  raised  If  the  ITERATOR  has  not  been  previously  set  by  ITERATE  or  if  the 
Iterator  Is  exhausted  (l.e.,  MORE  (ITERATOR)= FALSE)  or  If  INTENT  Is  an 
empty  array. 

LOCK  _  ERROR 

is  raised  if  the  opening  of  the  node  is  delayed  beyond  the  specified  TIME  _  LIMIT 
due  to  the  existence  of  locks  in  conflict  with  the  specified  INTENT. 

ACCESS  _  VIOLATION 

Is  raised  if  the  current  process'  discretionary  access  control  rights  are  Insufficient  to 
obtain  access  to  the  next  node  with  the  specified  INTENT.  Access  Violation  is 
raised  only  If  the  conditions  for  NAME_ERROR  are  not  present. 

S  EC  UR  ITY_  VIOLATION 

Is  raised  If  the  current  process'  attempt  to  obtain  access  to  the  next  node  with  the 
specified  INTENT  represents  a  violation  of  mandatory  access  controls  for  the  CAIS. 
SECURITY_VIOLATION  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

5.1.2.29.  Setting  the  current  node  relationship 

procedure  SET_cuRRE)rT_iiaDE (node:  in  node_type); 


Purpose: 

This  procedure  specifies  the  node  Identified  by  NODE  as  the  current  node.  The  relationship  of 
the  predefined  relation  CURRENT_NODE  of  the  current  process  Is  changed  accordingly. 

Parameters: 

NODE  Is  an  open  node  handle  to  a  node  to  be  the  new  target  of  the  CURRENT_NOI)K 

relationship  emanating  from  the  current  process  node. 

Exceptions: 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  Is  not  open. 

LOCK  _  ERROR 

Is  raised  If  access,  with  Inter  l  WRITE_RELATIONSlIIPS,  to  the  current  process 
node  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 
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SECURITY_  VIOLATION 

is  raised  if  the  operation  represents  a  .lolation  of  mandatory  access  controls. 
SECURITY_VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  set_current_node  (name  :  in  kame_string) 

ie 

MODE:  NODE_TYPE; 
begin 

OPEN (NODE ,  NAME.  (1=>EXISTENCE) ) ; 
SET_CURR£NT_NODE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  SET  CURRENT  NODE; 


5.1.2.30.  Opening  a  node  handle  to  the  current  node. 

procedure  get  current  node  (node:  in  out  nodetype; 

INTENT:  in  INTENTION : s 

(1=> EXISTENCE) ; 

TIME  LIMIT:  in  DURATION :=N0  DELAY); 


Purpose: 

This  procedure  returns  in  NODE  an  open  node  handle  to  the  curron  node  of  the  current 
process;  the  Intent  with  which  the  node  handle  is  opened  as  specii  d  by  the  INTENT 
parameter. 

Parameter: 

NODE  is  a  node  handle,  Initially  closed,  to  be  opened  to  the  current  node. 

INTENT  Is  the  Intent  of  subsequent  operations  on  the  node  handle  NODE. 

TIME_  LIMIT  Is  a  value  of  type  DURATION  specifying  a  time  limit  for  the  delay  on  waiting  for 
the  unlocking  of  the  node  in  accordance  with  the  desired  INTENT. 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  current  node  Is  inaccessible  or  If  it  is  unobtainable  and  the  INTENT 
Is  anything  other  than  EXISTENCE. 

USE  __  ERROR  Is  raised  If  INTENT  is  an  empty  array. 

STATUS _ ERROR 

is  raised  if  NODE  Is  an  open  node  handle  prior  to  the  call. 

LOCK  _  ERROR 

Is  raised  if  access,  with  Intent  READ_RELATIONSIIIPS,  to  the  current  process 
node  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 
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ACCESS_  VIOLATION 

is  raised  If  the  current  process'  discretionary  access  control  rights  are  insufficient  to 
obtain  access  to  the  current  node  with  the  specified  INTENT. 
ACCESS _ VIOLATION  Is  raised  only  If  the  conditions  for  NAME _  ERROR  are 
not  present. 

SECURITY  _  VIOLATION 

Is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_VIOLATION  Is  raised  only  If  the  conditions  other  exceptions  are  not 
present. 

Notes: 

The  call  on  GET_CURRENT_NODE  is  equivalent  to  OPEN(NODE,  " ’CURRENT _ NODE" . 
(INTENT,TIME_  LIMIT)). 

5.1.3.  Package  ATTRIBUTES 

This  package  supports  the  definition  and  manipulation  of  attributes  for  nodes  and  relationships.  The 
name  of  an  attribute  follows  the  syntax  of  an  Ada  Identifier.  The  value  of  each  attribute  is  a  list;  the 
format  of  the  list  Is  denned  by  the  package  LIST _ UTILITIES  (see  Section  5.4).  Upper  and  lower  case 
distinctions  are  not  signiHcant  within  the  attribute  names. 

Unless  stated  otherwise,  the  attributes  predefined  by  the  CAIS  cannot  be  created,  deleted  or  modified 
by  the  user. 

The  operations  denned  Tor  the  manipulation  of  attributes  Identify  the  node  to  which  an  attribute 
belongs  either  by  pathname  or  open  node  handle.  They  Implicitly  identify  a  relationship  to  which  an 
attribute  belongs  by  the  last  path  element  of  a  pathname  or  explicitly  Identify  the  relationship  by 
base  node,  key  and  relation  name  Identincatlon. 

5. 1.3.1.  Creating  node  attributes 

procedure  create  modeattribute (node :  in  mode  type; 

ATTRIBUTE:  in  ATTRIBUTE  JtAME; 

VALUE:  in  LIST  TYPE)”; 


Purpose: 

This  procedure  creates  an  attribute  named  by  ATTRIBUTE  of  the  node  identified  by  the  open 
node  handle  NODE  and  sets  Its  Initial  value  to  VALUE. 

Parameters: 

NODE  Is  an  open  node  handle  to  a  node  to  receive  the  new  attribute. 

ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  is  the  initial  value  of  the  attribute. 


Exceptions: 

,;SE_ERROR  Is  raised  If  the  node  already  has  an  attribute  of  the  given  name  or  if  the  attribute 

Page  3-136 


62 


PROI’O'KI)  Mil. -"TIM  \l" 
II  I  \M  VR1!  ink.-, 

name  given  is  syntactically  illegal.  USE_ERROR  is  also  raised  if  ATTRIBUTE  is 
the  name  of  a  predefined  node  attribute  which  cannot  be  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  is  not  open. 


INTENT  _  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  append 
attributes. 

SECURITY  _  VIOLATIO  N 

Is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_ VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

Additional  Interface: 

procedure  create_node_attri bute (name:  in  namestoing; 

ATTRIBUTE:  in  ATTRIBUTENAME ; 

VALUE :  in  LIST  TYPeF 

ia 

NODE:  NODE  TYPE; 
begin 

OPEN  (NODE,  NAME.  U=>  APPEND  ATTRIBUTES)  )  ; 

CREATE_NODE_ ATTRIBUTE (NODE . "ATTRIBUTE .  VALUE) ; 

CLOSE (NODE) ; 
exception 

when  others  »> 

CLOSE (NODE) ; 
raise; 

end  CREATE  NODE  ATTRIBUTE; 


5. 1.3.2.  Creating  path  attributes 


procedure  create  path  attribute  (base  : 

KEY: 

RELATION: 

ATTRIBUTE: 

VALUE: 


in  NODETYPE; 
in  RELATIONSHIP  JOEY: 
in  RELATION  NAME 
: =DEFAULT_RELATION ; 
in  ATTRIBUTENAME; 
in  LIST  TYPE); 


Purpose: 

This  procedure  creates  an  attribute,  named  by  ATTRIBUTE,  of  a  relationship  and  sets  Its  initial 
value  to  VALUE.  The  relationship  is  identified  by  the  base  node  identified  by  the  open  node 
handle  BASE,  the  relation  name  RELATION  and  the  relationship  key  KEY. 


Parameters: 

BASE  Is  an  open  node  handle  to  the  node  from  which  the  relationship  emanates. 

KEY  Is  the  relationship  key  of  the  affected  relationship. 

RELATION  is  the  relation  name  of  the  affected  relationship. 
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ATTRIBUTE  Is  the  attribute  name. 

VALUE  Is  the  Initial  value  of  the  attribute. 

Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  relationship  Identified  by  the  BASE,  KEY  and  RELATION 
parameters  does  not  exist. 

USE_  ERROR  Is  raised  if  the  relationship  already  has  an  attribute  of  the  given  name  or  if  the 
attribute  name  given  is  syntactically  Illegal.  USE_ ERROR  Is  also  raised  if 
RELATION  Is  the  name  of  a  predefined  relation  that  cannot  be  modified  by  the 
user.  USE_ ERROR  Is  also  raised  If  ATTRIBUTE  Is  the  name  of  a  predefined 
relationship  attribute  which  cannot  be  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  the  node  handle  BASE  is  not  open. 

INTENT  _  VIOLATION 

Is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  write 
relationships. 

SECURITY_  VIOLATION 

is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_  VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

Additional  Interface: 

procedure  create_path_attribute  (name  :  in  namestring; 

ATTRIBUTE:  in  ATTRIBUTE JMKE; 

VALUE:  in  LIST  TYPEr 

is 

BASE:  NODETYPE; 
begin 

OPEN (BASE .  BASE  PATH (MAKE) ,  (1=>WRITE  RELATIONSHIPS)); 

CREATE  PATH  ATTRIBUTE (BASE.  LAST  KEY (NAME),  LAST_RELATION(MAME) , 

ATTRIBUTE . _VALUE) ; 

CLOSE (BASE) ; 
exception 

when  others  => 

CLOSE (BASE) ; 

raise; 

end  CREATE  PATH  ATTRIBUTE; 


5. 1.3.3.  Deleting  node  attributes 

procedure  delete_nooe_attribute (node :  in  nodejtype; 

ATTRIBUTE:  in  ATTrIbUTE  NAME)  ; 

Purpose: 

This  procedure  deletes  an  attribute,  named  by  ATTRIDUTK,  of  the  node  identified  by  the  open 
node  handle  NOOK. 
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Parameters: 

NODE  Is  an  open  node  handle  to  a  node  whose  attribute  Is  to  h  -  deleted. 

ATTRIBUTE  Is  the  name  of  the  attribute  to  be  deleted. 


Exceptions: 

USE_ERROR  is  raised  if  the  node  does  not  have  an  attribute  of  the  given  name.  USE_ERROR  is 
also  raised  If  ATTRIBUTE  Is  the  name  of  a  predefined  node  attribute  which  cannot 
be  modified  or  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  the  node  handle  NODE  is  not  open. 

INTENT  _  VIOLATION 

Is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  write 
attributes. 

SECURITY  _  VIOLATION 

Is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY^ VIOLATION  Is  raised  only  if  the  conditions  Tor  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  DELETE_RODE_ATTRIBUTE  (NAME  :  in  KAVESTRING ; 

ATTRIBUTE:  in  ATTRIBUTEMAME) 

ia 

RODE:  RODE  TYPE; 
begin 

OPEH (RODE ,  RARE.  (1=>WRITE  ATTRIBUTES) ) ; 
DELETE_R0DE_ATTRIBUTE(R0DE7  ATTRIBUTE); 

CLOSE  (RODE) ; 
exception 

when  othera  => 

CLOSE  (RODE) ; 
raise; 

end  DELETE  RODE  ATTRIBUTE; 


5. 1.3.4.  Deleting  path  attributes 


procedure  delete_path_attribute (base :  in  rode  type; 

KEY:  in  RELATIONSHIPKEY; 

RELATION:  in  RELATIOHHAKE 

: =DEFAULT_RELATIOR ; 
ATTRIBUTE:  in  ATTRIBUTE  NAVE) ; 


Purpose: 


This  procedure  deletes  an  attribute,  named  by  ATTRIBUTE,  of  a  relationship  identified  by  the 
base  node  BASE,  the  relation  name  RELATION  and  the  relationship  key  KEY. 


Parameters: 

BASE  is  an  open  node  handle  to  the  node  from  which  the  relationship  emanates. 
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KEY  Is  the  relationship  key  of  the  affected  relationship. 

RELATION  Is  the  relation  name  of  the  affected  relationship. 
ATTRIBUTE  Is  the  attribute  name  of  the  attribute  to  be  deleted. 


Exceptions: 

NAME  _  ERROR 

Is  raised  if  the  relationship  identified  by  the  BASE,  KEY  and  RELATION 
parameters  does  not  exist. 

USE_ ERROR  is  raised  if  the  relationship  does  not  have  an  attribute  of  the  given  name. 

USE_  ERROR  is  also  raised  if  RELATION  is  the  name  of  a  predefined  relation  that 
cannot  be  modified  by  the  user.  USE_ ERROR  is  also  raised  if  ATTRIBUTE  is  the 
name  of  a  predefined  relationship  attribute  which  cannot  be  modified  by  the  user. 

STATUS _ ERROR 

is  raised  if  the  node  handle  BASE  is  not  open. 

INTENT  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  write 
relationships. 

SECURITY_  VIOLATION 

Is  raised  If  the  operation  represents  a  violation  oT  mandatory  access  controls. 
SECURITY _ VIOLATION  Is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  delete_path_attribute  (name  :  in  namestring; 

ATTRIBUTE:  in  ATTRIBUTE JIAME) 

is 

BASE:  N0DE_TYPE; 
begin 

OPEN (BASE.  BASE_PATH (NAME) .  (1=>WRITE_RELATI0NSHIPS) ) ; 

DELETE  PATH  ATTRIBUTE (BASE ,  LAST  KEY (NAME) .  LAST  RELATION (NAME) . 
ATTRIBUTE)? 

CLOSE (BASE) ; 
exception 

when  others  => 

CLOSE (BASE) ; 

raise; 

end  DELETE_PATH_ATTR  I  BUTE ; 


5.1. 3.5.  Setting  node  attributes 

procedure  set_node_attribute (node :  in  node  type; 

ATTRIBUTE:  in  ATTRIBUTENAME ; 

VALUE:  in  LIST  TYPE?; 

Purpose: 

This  procedure  sets  the  value  of  the  node  attribute  named  by  ATTRIBUTE  to  the  value  given 
by  VALUE.  The  node  is  identified  by  an  open  node  handle  NODE. 
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Parameters: 

NODE  is  an  open  node  handle  to  a  node  the  value  of  whose  attribute  named  by 

ATTRIBUTE  is  to  be  set. 

ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  is  the  new  value  of  the  attribute. 


Exceptions: 

USE_ERROR  is  raised  if  the  node  has  no  attribute  of  the  given  name.  USE_ ERROR  is  also 
raised  if  ATTRIBUTE  is  the  name  of  a  predefined  node  attribute  which  cannot  be 
modified  by  the  user. 

STATUS_ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 

INTENT_  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  write 
attributes. 

SECURITY_  VIOLATION 

Is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY _ VIOLATION  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  set_node_attribute<name:  in  namestring; 

ATTRIBUTE:  in  ATTRIBUTENAME; 
VALUE :  in  LIST  TYPE^ 

is 

MODE:  MODE  TYPE; 
begin 

OPEM (NODE .  NAME.  (1=>WRITE  ATTRIBUTES) ) ; 

SET  MODE  ATTRIBUTE (MODE.  ATTRIBUTE,  VALUE); 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (MODE) ; 
raise; 

end  SET  NODE  ATTRIBUTE; 


5. 1.3.0.  Setting  path  attributes 


procedure  set_path_attribute  (base 

KEY 

RELATION  : 

ATTRIBUTE : 
VALUE 


:  in  NODETYPE; 
in  RELATIONSHIP_KEY; 
in  RELATION  NAME 

: =DEFAULT_RELATION ; 
in  attribute'name, 
in  LIST  TYPE); 


Purpose: 


This  procedure  sets  the  value  of  the  relationship  attribute  named  by  ATTRIMUTK  lo  the  value 
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specified  by  VALUE.  The  relationship  Is  identified  explicitly  by  the  base  node  BASE,  the 
relation  name  RELATION  and  the  relationship  key  KEY. 

Parameters: 

BASE  Is  an  open  node  handle  to  the  node  from  which  the  relationship  emanates. 

KEY  Is  the  relationship  key  of  the  affected  relationship. 

RELATION  Is  the  relation  name  of  the  affected  relationship. 

ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  is  the  new  value  of  the  attribute. 


Exceptions: 

NAME  ERROR 

is  raised  if  the  relationship  identified  by  the  BASE,  KEY  and  RELATION 
parameters  does  not  exist. 

USE _  ERROR  Is  raised  If  the  node  does  not  have  an  attribute  of  the  given  name.  USE _  ERROR 
is  also  raised  if  RELATION  is  the  name  of  a  predefined  relation  that  cannot  be 
modified  by  the  user.  USE  _  ERROR  Is  also  raised  If  ATTRIBUTE  i9  the  name  of  a 
predefined  relationship  attribute  which  cannot  be  modified  by  the  user. 

STATUS _ ERROR 

Is  raised  if  the  node  handle  BASE  is  not  open. 

INTENT  _  VIOLATION 

Is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  write 
relationships. 

SECURITY  _  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_ VIOLATION  is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  set_path_attribute (name :  in  name  string; 

ATTRIBUTE:  in  ATTRIBUTEJtAME ; 
VALUE :  in  LIST_TYPE)" 

is 

BASE:  NODE_TYPE ; 
begin 

OPEN (BASE ,  BASE_PATH(NAME) .  (1=>WRITE_RELATI0NSHIPS)) ; 
SET_PATH_ATTRIBUTE (BASE .  LAST JCEY (NAME) ,  LAST  RELATION (NAME) , 
ATTRIBUTE. "VALUE) ; 

CLOSE (BASE) ; 
exception 

when  others  => 

CLOSE (BASE) ; 

raise: 

end  SET  PATH  ATTRIBUTE; 
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5. 1.3.7.  Getting  node  attributes 

procedure  get_node_attribute  (node  :  in  node  type; 

ATTRIBUTE:  in  ATTRIBUTENAME; 

VALUE:  in  Out  LIST  TYPE); 

Purpose: 

This  procedure  returns  the  value  of  the  node  attribute  named  by  ATTRIBUTE  In  the  parameter 
VALUE.  The  node  Is  identified  by  open  node  handle  NODE. 


Parameters: 

NODE  is  an  open  node  handle  to  a  node  the  value  of  whose  attribute  ATTRIBUTE  is  to  be 

retrieved. 

ATTRIBUTE  is  the  name  of  the  attribute. 

VALUE  Is  the  result  parameter  containing  the  value  of  the  attribute. 

Exceptions: 

USE_ ERROR  Is  raised  if  the  node  has  no  attribute  of  name  ATTRIBUTE. 

STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 

INTENT_  VIOLATION 

Is  raised  If  NODE  was  not  opened  with  an  Intent  establishing  the  right  to  read 
attributes. 


Additional  Interface: 

procedure  get_node_attribute  (name  :  in  namestring; 

ATTRIBUTE:  in  ATTRIBUTENAME ; 
VALUE.  in  OUt  LISTJYPE) 

ia 

NODE:  NODETYPE; 
begin 

OPEN (NODE .  NAME.  (1=>READ  ATTRIBUTES)); 

GET_NODE_ATTH I BUTE (NODE ,  ATTRIBUTE,  VALUE); 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  GET  NODE  ATTRIBUTE; 


5. 1.3. 8.  Getting  path  attributes 


procedure  get  path  atthibutecbase: 

in 

NODE_TYPE ; 

KEY: 

in 

RELATIONSHIPJCEY; 

RELATION: 

in 

RELATION  NAME 
: =DEFAULT_RELATION; 

ATTRIBUTE: 

in 

ATTRIBUTE_NAME ; 

VALUE: 

in 

OUt  LIST  TYPE)  ; 

Purpose: 
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This  procedure  assigns  the  value  of  the  relationship  attribute  named  by  ATTRIBUTE  to  the 
parameter  VALUE.  The  relationship  Is  Identified  explicitly  by  the  base  node  BASE,  the  relation 
name  RELATION  and  the  relationship  key  KEY. 


Parameters: 

BASE 

KEY 

RELATION 

ATTRIBUTE 

VALUE 


is  an  op>-n  node  handle  to  the  node  from  which  the  relationship  emanates, 
is  the  relationship  key  of  the  accessed  relationship, 
is  the  relation  name  of  the  accessed  relationship. 

Is  the  name  of  the  attribute. 

Is  the  result  parameter  containing  the  value  of  the  attribute. 


Exceptions: 

NAME_  ERROR 

is  raised  if  the  relationship  Identified  by  the  BASE,  KEY  and  RELATION 
parameters  does  not  exist. 


USE_ ERROR  Is  raised  if  the  relationship  does  not  have  an  attribute  or  the  given  name. 
STATUS _ ERROR 

is  raised  If  the  node  handle  BASE  Is  not  open. 


INTENT  _  VIOLATION 

is  raised  If  BASE  was  not  opened  with  an  Intent  establishing  the  right  to  read 
relationships. 

Additional  Interface: 

procedure  get_path_attribute(nake:  in  nakestring; 

ATTRIBUTE:  in  ATTRIBUTEJtAME; 

VALUE:  in  out  LIST_TYPe1 

is 

RASE:  NODEJTYPE; 
begin 

□PEN (BASE,  BASE  PATH (NAME) ,  (1=>READ  RELATIONSHIPS)): 

GET_PATH_ATTR I BUTE (BASE .  LAST JCEY (NAME) ,  LAST  RELATION(NAME) . 

ATTRIBUTE ,  VALUE) ; 

CLOSE (BASE) ; 
exception 

when  others  => 

CLOSE (BASE) ; 

raise: 

end  GET_PATH_ATTRIBUTE; 
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5. 1.3.0.  Attribute  iteration  types  and  subtypes 

subtype  attr i bute_nane  is  string; 

type  attribute  iterator  is  limited  private; 

subtype  attribute_pattern  is  string; 

These  types  are  used  in  the  following  interfaces  for  iteration  over  a  set  of  attributes  of  nodes  or 
relationships.  ATTRIBUTE_NAME  Is  a  subtype  for  the  names  of  attributes.  An 

ATTR1BUTE_ PATTERN  has  the  same  syntax  as  an  ATTRIBUTE_NAME.  except  that  will 

match  any  single  character  and  will  match  any  string  of  characters.  ATTRIBUTE^  ITERATOR  is 
a  private  type  assumed  to  contain  the  bookkeeping  information  necessary  for  the  implementation  of 
the  MORE  and  GET _ NEXT  functions.  The  attributes  are  returned  by  GET _  NEXT  in  ASCII 
lexicographical  order  by  attribute  name.  The  effect  on  existing  Iterators  of  creation  or  deletion  of 
attributes  or  relationships  is  implementation-defined. 


5. 1.3. 10.  Creating  an  iterator  over  node  attributes 


procedure  node_attribute_iterate (iterator: 

NODE: 


PATTERN: 


Purpose: 


OUt  ATTRIBUTEITERATOR; 
in  NODE  TYPE  •” 

in  ATTRIBUTE  PATTERN 

=*•*); 


The  procedure  NODE _ ATTRIBUTE _  ITERATE  returns  in  the  parameter  ITERATOR  an 
attribute  iterator  according  to  the  semantic  rules  for  attribute  selection  given  in  Section  5. 1.3.9. 


Parameters: 

ITERATOR  is  the  attribute  iterator  returned. 

NODE  is  an  open  node  handle  to  a  node  over  whose  attributes  the  iterator  is  to  be 

constructed. 

PATTERN  is  a  pattern  for  attribute  names  as  I  escribed  in  Section  5. 1.3.9. 

Exceptions: 

USE_ ERROR  Is  raised  if  the  PATTERN  is  syntactically  Illegal. 

STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 


INTENT  _  VIOLATION 

is  raised  if  NODE  Is  not  open  with  an  intent  establishing  the  right  to  read 
attributes. 


Additional  Interface: 


procedure  node_attribute_iterate (iterator: 

MANE: 

PATTERN: 

is 

NODE:  N0DE_TYPE; 
begin 


out  ATTRIBUTE_ITERATOR ; 

in  nanestrFng  ; 

in  attributepattern 

:=•*•) 
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OPEN (NODE.  NAME.  (1=>READ  ATTRIBUTES) ) ; 

NODEJlTTRIBUTE_ITERATE(  ITERATOR,  NODE,  PATTERN); 

CLOSE (NODE) ; 
exception 

when  other*  => 

CLOSE (NODE) ; 
raise; 

end  NODE_ATTRIBUTE_ITERATE; 

Notes: 

By  using  the  pattern  It  is  possible  to  Iterate  over  all  attributes  of  a  node. 

5.1.3.11.  Creating  an  iterator  over  relationship  attributes 

procedure  path  attribute_iterate (iterator:  out  attribute_iterator; 

BASE:  in  N0DE_TYPE  ~ 

KEY:  in  RELATIONSHIP_KEY; 

RELATION:  in  RELATION  NAME 

: =DEFAULT_RELATION ; 

PATTERN:  in  ATTRIBUTE  PATTERN 

.=•*•); 

Purpose: 

This  procedure  Is  provided  to  obtain  an  attribute  iterator  for  relationship  attributes.  The 
relationship  is  identified  explicitly  by  the  base  node  BASE,  the  relation  name  RELATION  and 
the  relationship  key  KEY.  The  procedure  returns  an  attribute  iterator  In  ITERATOR  according 
to  the  semantic  rules  for  attribute  selection  applied  to  the  attributes  of  the  identified 
relationship.  This  iterator  can  then  be  processed  by  means  of  the  MORE  and  GET _  NEXT 
Interfaces. 

Parameters: 

ITERATOR  is  the  attribute  Iterator  returned. 

BASE  Is  an  open  node  handle  to  the  node  from  which  the  relationship  emanates. 

KEY  is  the  relationship  key  of  the  affected  relationship. 

RELATION  Is  the  relation  name  of  the  affected  relationship. 

PATTERN  Is  a  pattern  for  attribute  names  (see  Section  5. 1.3. 9). 

Exceptions: 

NAME_  ERROR 

Is  raised  if  the  relationship  identified  by  the  BASE,  KEY  and  RELATION 
parameters  does  not  exist. 

USE_ ERROR  is  raised  if  the  PATTERN  Is  syntactically  Illegal. 

STATUS _ ERROR 

Is  raised  If  BASE  Is  not  an  open  node  handle. 

INTENT  _  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  read 
relationships. 
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Additional  Interface: 

procedure  path_attribute_iterate  (iterator :  out  attribute_ iterator; 

MAKE:  in  NAMESTRING; 

PATTERN:  in  ATTRIBUTE  PATTERN 

:=*•*> 

is 

BASE:  NODE_TYPE; 
begin 

OPEN (BASE ,  BASEPATH (NAME) ,  (1=>READ_RELATI0NSHIPS) ) ; 

PATH  ATTRIBUTE_ITERATE (ITERATOR,  BASE.  LAST_KEY (NAME) , 
LAST_RELATION (NAME) PATTERN) ; 

CLOSE (BASE); 
exception 

when  others  => 

CLOSE (BASE) ; 
raise; 

end  PATH  ATTRIBUTE  ITERATE; 


5.1.3.12.  Determining  iteration  status 

function  MORE  (ITERATOR:  in  ATTRIBUTE^ TERATOR) 
return  boolean; 


Purpose: 

The  function  MORE  returns  FALSE  If  all  attributes  contained  In  the  attribute  iterator  have 
been  retrieved  with  the  procedure  GET_NEX'f;  otherwise.  It  returns  TRUE. 

Parameters: 

ITERATOR  Is  an  attribute  Iterator  previously  constructed. 


Exceptions: 

USE_ERROR  Is  raised  if  the  ITERATOR  has  not  been  previously  set  by  the  procedures 
NOr>E_ATTRIBUTE_ ITERATE  or  PATH_ ATTRIBUTE _ ITERATE. 

5.1.3.13.  Getting  the  next  attribute 

procedure  getnext (iterator:  in  out  attribute  iterator; 

ATTRIBUTE:  OUt  ATTRIBUTE_NAME ; 

VALUE:  in  OUt  LIST_TTPE)7 

Purpose: 

The  procedure  GET_NEXT  returns,  In  Its  parameters  ATTRIBUTE  and  VALUE,  both  the 
name  and  the  value  of  the  next  attribute  In  the  Iterator. 


Parameters: 

ITERATOR  Is  an  attribute  Itcrator  previously  constructed. 

ATTRIBUTE  Is  a  result  parameter  containing  the  name  of  an  attribute. 

VALUE  is  a  result  parameter  containing  the  value  of  the  attribute  named  by  ATTRIBUTE. 

Exceptions: 

Usc,_ ERROR  Is  raised  if  the  ITERATOR  has  not  been  previously  set  by  the  procedures 
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NODE_ATTRIBUTE_ ITERATE  or  PATH _ ATTRIBUTE _ ITERATE  or  if  the 
iterator  is  exhausted,  l.e.,  MORE(lTERATOR)=  FALSE. 


5.1.4.  Package  ACCESS— CONTROL 

This  package  provides  primitives  for  manipulating  discretionary  access  control  information  for  CAIS 
nodes.  In  addition,  certain  CAiS  subprograms  declared  elsewhere  allow  the  specification  of  initial 
access  control  information.  The  CAIS  specifies  mechanisms  for  discretionary  and  mandatory  access 
control  (see  [TCSEC)).  These  mechanisms  are  only  recommendations.  Alternate  discretionary  or 
mandatory  access  control  mechanisms  can  be  substituted  by  an  Implementation  provided  that  the 
semantics  of  all  interfaces  in  Section  5  (with  the  exception  of  Section  5.1.4)  are  implemented  as 
specified. 

5.I.4.I.  Subtypes 

subtype  GRANTVALUE  is  CAIS.LIST_trriLITIES.LIST_TYPE; 

GRANT_  VALUE  is  a  subtype  for  values  of  GRANT  attributes;  It  Is  a  list  in  the  syntax  described  in 
Table  II. 


5.I.4.2.  Setting  access  control 


procedure  set  access  control  (mode  :  in  node_type; 

ROLE  NODE:  in  NODEJTYPE; 
GRANT:  in  GRANTVALUE) ; 


Purpose: 


This  procedure  sets  access  control  information  for  a  given  node.  If  a  relationship  of  the 
predefined  relation  ACCESS  does  not  exist  from  the  node  Identified  by  NODE  to  the  node 
identified  by  ROLE_NODE,  such  a  relationship  with  an  implementation-denned  relationship 
key  Is  created  from  the  node  specified  by  NODE  to  the  node  specified  by  ROI,E_NOI)E.  If 
necessary,  the  predefined  attribute  GRANT  Is  created  on  this  relationship.  The  value  of  the 
GRANT  attribute  is  set  to  the  value  of  the  GRANT  parameter  (see  Table  II  for  the  syntax). 
The  effect  Is  to  grant  the  access  specified  by  GRANT  to  processes  that  have  adopted  the  role 
ROLE  NODE. 


Parameters: 

NODE  is  an  open  node  handle  to  the  node  whose  access  control  Information  is  to  be  set. 

ROLE_NODE 

is  an  open  node  handle  to  the  node  representing  the  role. 

GRANT  is  a  list  describing  what  access  rights  can  be  granted. 


Exceptions: 

USE_ERROR  is  raised  If  GRANT  is  not  In  valid  syntax. 

STATUS _ ERROR 

is  raised  If  NODE  and  ROI.E_NODE  are  not  both  open  node  handles. 
INTKNT_  VIOLATION 

Is  raised  if  NODE  was  not  opened  with  intent  CONTROL. 
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SECURITY  VIOL  \TlON 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY _  VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  set_access _ccntrol  (make  :  in  kame_string; 

ROL£_NAME:  in  NAME~ STRING; 
GRANT:  in  GRANT_VALUE) 

is 

NODE,  ROLE_NODE:  NODE_TYPE; 
begin 

OPEN (NODE ,  NAME.  (1=>C0NTR0L) ) ; 

OPEN (R0LE_N0DE .  ROLENAME,  (1=>EXISTENCE) ) ; 
SET_ACCESS_CONTROL (NODE .  ROLENODE,  GRANT); 

CLOSE (NODEr; 

CLOSE (ROLE_NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 

CLOSE (ROLENODE) ; 
raise; 

end  SET  ACCESS_CONTROL; 


5. 1.4. 3.  Examining  access  rights 

function  isgranted  (object  node  :  in  node_type; 

ACCEsi_RIGHT :  in  KAMB_STRING) 
return  boolean 

Purpose: 

This  function  returns  TRUE  if  the  current  process  as  a  subject  has  an  approved  access  right 
ACCESS  RIGHT  to  the  OBJECT  NODE  as  an  object.  Otherwise  it  returns  FALSE. 


Parameters: 

OBJECT  _  NODE 

is  an  open  node  handle  to  the  object  node. 


ACCESS  _  RIGHT 

Is  the  name  of  a  predefined  or  user-defined  access  right. 


Exceptions: 

USE_ERROR  is  raised  if  ACCESS_RIGHT  Is  not  a  valid  Ada  identifier. 

STATUS _ ERROR 

Is  raised  if  OBJECT  _  NODE  Is  not  an  open  node  handle. 

INTENT  _  VIOLATION 

is  raised  if  OBJECT_NODE  was  not  opened  with  an  intent  establishing  the  right 
to  read  relationships  or  to  read  access  control  information. 


Additional  Interface: 
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function  IS_GRANTED(OBJECT_NAME:  in  KAME_STRING; 

ACCEsi_RIGHT :  in  NAMisTRING) 
return  boolean 

is 

OB JECT_NODE :  NODE  TYPE; 

RESULT?  BOOLEAN; 

begin 

OPEN (OB JECT_NODE .  OB JECT_NAME .  (1=>READ_RELATX0NSHIPS) ) ; 
RESULT  :=  IS  GRANTED (OBJECT  NODE.  ACCEsi  RIGHT); 

CLOSE (OBJECT~NODE) ; 

return  result; 

exception 

when  others  => 

CLOSE (OB JECTNODE) ; 

raise; 

end  IS  GRANTED; 


5. 1.4.4.  Adopting  a  role 

procedure  adopt  (rolenooe:  in  node_type; 

ROLE~  KEY :  in  RELATIONSHIPKEY : =  LATEST  KEY); 


Purpose: 

This  procedure  causes  the  current  process  to  adopt  the  group  specified  by  the  ROLE_NODR.  A 
relationship  of  the  predefined  relation  ADOPTED_ROLE  with  relationship  key  ROLE_KEY  is 
created  from  the  calling  process  node  to  the  node  identified  by  ROLE_NODB.  In  order  for  the 
current  process  to  adopt  the  group,  a  node  representing  some  other  adopted  role  of  the  current 
process  must  be  a  potential  member  of  the  group  to  be  adopted. 

Parameters; 

ROLE_NODE 

Is  an  open  node  handle  to  a  node  representing  the  group. 

ROLE _  KEY  is  a  relationship  key  to  be  used  In  creating  the  relationship. 

Exceptions: 

USE_ ERROR  Is  raised  if  there  is  no  adopted  role  of  the  current  process  that  is  a  potential 
member  of  the  group  represented  by  ROLE_NODE  or  If  there  already  exists  a 
relationship  of  the  predefined  relation  ADOPTED _  ROLE  with  relationship  key 
ROLE_KEY  emanating  from  the  current  process  node.  USE_ERROR  is  also 
raised  if  the  node  identified  by  ROLE _  NODE  Is  Inaccessible  or  unobtainable. 

STATUS _ ERROR 

Is  raised  if  ROLE  _  NODE  is  not  an  open  node  handle. 

LOCK  _  ERROR 

Is  raised  If  access  with  Intent  APPEND_RELATIONSHIPS  to  the  current  process 
node  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

SECURITY  _  VIOLATION 

Is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_ VIOLATION  is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 
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5. 1.4. 5.  Unlinking  an  adopted  role 

procedure  unadopt (rolejcey :  in  relationship_key)  ; 


Purpose: 

This  procedure  deletes  the  relationship  of  the  predefined  relation  ADOPTRl)_ ROLE  with 
relationship  key  ROLE_KEY  emanating  from  the  current  process  node.  If  there  is  no  such 
relationship,  the  procedure  has  no  effect. 

Parameters: 

ROLE _  KEY  is  the  relationship  key  of  the  relation  ADOPTED _  ROLE 
Exception: 

USE_ ERROR  Is  raised  if  the  target  node  of  the  relationship  to  be  deleted  is  the  top-level  node 
identified  by  "’CURRENT_USER".  In  this  case  the  relationship  is  not  deleted. 

LOCK  _  ERROR 

is  raised  if  access,  with  intent  WRITE_ RELATIONSHIPS,  to  the  current  process 
node  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 


5.1.5.  Package  STRUCTURAL _ NODES 

Structural  nodes  are  special  nodes  In  the  sense  that  they  do  not  have  contents  as  the  other  nodes  of 
the  CAIS  model  do.  Their  purpose  Is  solely  to  be  carriers  or  common  Information  about  other  nodes 
related  to  the  structural  node.  Structural  nodes  are  typically  used  to  create  conventional  directories, 
configuration  objects,  etc.. 

The  package  STRUCTURAL_  NODES  defines  the  primitive  operations  for  creating  structural  nodes. 

5.1.5. 1.  Creating  structural  nodes 

procedure  create  node  (mode:  in  out  modetype; 


BASE: 

in 

N0DE_TYPE; 

KEY: 

in 

RELATIONSHIP  KEY 

: =LATEST_KEY ; 

RELATION : 

in 

RELATION_NAME 

:=DEFAULT  RELATION; 

ATTRIBUTES: 

in 

LIST_TYPE  :=  EMPTY_LIST; 

ACCESS_CONTRQL : 

in 

LIST~TYPE  :=  ENPTy'lIST; 

LEVEL:" 

in 

LISt"tYPE  :=  EMPTYLIST) 

Purpose: 

This  procedure  creates  a  structural  node  and  installs  the  primary  relationship  to  it.  The  relation 
name  and  relationship  key  of  the  primary  relationship  to  the  node  and  the  base  node  from  which 
It  emanates  are  given  by  the  parameter-  RELATION,  KEY,  and  BASE.  An  open  node  handle 
to  the  newly  created  node  with  WRITE  intent  Is  returned  in  NODE. 


The  ATTRIBUTES  parameter  defines  and  provides  initial  values  for  attributes  of  the  node.  The 
ACCESS_CONTROL  parameter  specifics  Initial  access  control  Informal  Ion  to  be  established  for 
the  created  node  ( <ee  Section  4.4). 


The  LEVEL  parameter  specifies  the  security  level  at  which  the  node  is  to  be  created. 
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Parameters: 

NODR 


Is  a  node  handle.  Initially  closed,  to  be  opened  to  the  newly  created  node. 


BASR  is  an  open  node  handle  to  the  node  from  which  the  primary  relationship  to  the  new 

node  Is  to  emanate. 

KEY  is  the  relationship  key  of  the  primary  relationship  to  be  created. 

RELATION  Is  the  relation  name  of  the  primary  relationship  to  be  created. 

ATTRIBUTES  Is  a  named  list  (see  Section  5.4)  whose  elements  are  used  to  establish  initial  values 
for  attributes  of  the  newly  created  node;  each  named  item  specifies  an  attribute 
name  and  the  value  to  be  given  to  that  attribute. 

ACCESS  _  CONTROL 

Is  the  Initial  access  control  Information  associated  with  the  created  node:  it  is  a 
named  list  (see  Section  5.4)  each  of  whose  named  items  specifies  a  relationship  key 
followed  by  a  list  of  access  rights. 


LEVEL 


is  the  classification  label  for  the  created  node  (see  TABLE  IV). 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  a  node  already  exists  for  the  node  Identification  given.  If  the  node 
identification  Is  illegal,  or  if  any  node  identifying  a  group  specified  in  the  given 
ACCESS_CONTROL  parameter  Is  unobtainable  or  inaccessible. 

USE_ERROR  is  raised  if  the  ACCESS _ CONTROL  or  LEVEL  parameters  do  not  adhere  to  the 
required  syntax  or  if  the  ATTRIBUTES  parameter  contains  references  to  predefined 
attributes  which  cannot  be  modified  or  created  by  the  user.  USE_ERROR  is  also 
raised  If  RELATION  is  the  name  of  a  predefined  relation  that  cannot  be  modified 
or  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  BASE  is  not  an  open  node  hnndle  or  If  NODE  is  an  open  node  handle 
prior  to  the  call. 

INTENT  _  VIOLATION 

is  raised  If  BASE  was  not  opened  with  an  intent  establishing  the  right  to  append 
relationships. 

SECURIT  Y_  V IOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  acct'ss  controls. 
SECURlTY_VIOLAT!ON  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interfaces: 

procedure  create_node(nodE: 

NAME: 
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ATTRIBUTES:  in  LIST_TYPE  :=  EMPTY_LIST; 

ACCESS_C0NTR0L :  in  LISTJYPE  :=  EMPTy'lIST; 

LEVEL:"  in  LISt’tYPE  :=  EMPTY-LIST5 ; 

is 

BASE:  NCDE_TYPE ; 
begin 

OPEN (BASE .  BASE  J»ATH  (NAME) .  (1=>APPEND_R£LATI0NSHIPS) )'; 
CR£ATE_NODE (NODE .  BASE.  LAST JCEY (NAME) 7  LAST_RELATION (NAME) , 
ATTRIBUTES .  ACCESS_CONTROL ,  LEVEL) : 

CLOSE (BASE): 
exception 

when  others  => 

CLOSE  (NODE) : 

CLOSE (BASE) ; 
raise; 

end  CREATE  NODE; 


procedure  create_node  (base  : 

KEY: 


in  NODE_TYPE : 

in  relationship  key 


: =LATEST_KEY ; 

RELATION:  in  RELATION  NAME 

: -DEFAULT  RELATION; 

ATTRIBUTES:  in  LIST_TYPE  :»  EMPTY_LIST; 

ACCESS _CONTROL :  in  LISt'tYPE  :*  EMPTY-LIST: 

LEVEL:”  in  LIST~TYPE  :=  EMPTY  LIST; 


NODE;  NODE_TYPE; 
begin 

CREATE  NODE (NODE. KEY, RELATION. ATTRIBUTES, ACCESS  CONTROL. LEVEL) ; 
CLOSE (NODE) : 
end  CREATE  NODE; 


procedure  create_node  (NAME:  in  name_STRIng . 

ATTRIBUTES:  in  LIST_TYPE  :=  EMPTY_LIST ; 

ACCESS_CQ NTROL :  in  LIST~TYPE  :=  EMPTYJ.IST; 

LEVEL:”  in  LISTJTYPE  :=  EMPTYJ.IST) : 

is 

NODE:  NODETYPE ; 
begin 

CREATE_NODE (NODE .  NAME.  ATTRIBUTES.  ACCESS_CONTROL.  LEVEL); 

CLOSE (NODE); 
end  CREATE_NODE ; 

Notes; 

Use  of  the  sequence  of  a  CREATE  _  NODE  call  that  does  not  return  an  open  node  handle 
followed  by  a  call  on  OPEN  for  the  created  node,  using  the  node  identification  of  the  created 
node,  cannot  guarantee  that  a  handle  to  the  node  just  created  is  opened:  this  is  because 
relationships,  and  therefore  the  node  identification,  may  have  changed  since  the 
CREATE  NODE  call. 


5.2.  CAIS  process  nodes 


This  section  describes  the  semantics  of  the  execution  of  Ada  pmcams  as  represented  by  CAJS 
processes  and  the  facilities  provided  by  the  CAIS  for  initiating  and  >  ■  ntrolllng  processes.  The  major 
stages  In  a  process'  life  are  initiation,  running  (which  may  Include  ispension  or  resumption),  and 
termination  or  abortion.  The  CAIS  dc'lnes  facilities  to  coni  mi  nd  coordinate  the  initiation, 
suspension,  resumption,  and  termination  r  abortion  of  processes  >e  Section  4. .1.2).  Each  CAIS 
process  has  a  current  status  associated  w  h  it  which  changes  wii  •  -rtain  events  as  specified  in 


TABLE  VI. 


Page  3-153 


79 


PROPOSKD  Mlb-STD-C  AIS 
.11  JANTARV  IASS 

A  process  is  said  to  be  terminated  when  its  main  program  (in  the  sense  of  I.RMj  10. 1 )  has  terminated 
(in  the  sense  of  [LRMj  9.4).  See  also  the  notes  in  (LRM|  9  4.  Thus,  termination  of  a  process  takes 
place  when  the  main  program  has  been  completed  and  all  tasks  dependent  on  the  main  program  have 
terminated.  A  process  may  be  aborted  either  by  itself  or  by  another  process.  When  a  process  has 
terminated  or  has  been  aborted,  all  of  its  dependent  processes  which  have  not  already  terminated  or 
been  aborted  will  be  aborted  but  its  process  node  remains  until  explicitly  deleted.  Any  open  node 
handles  of  a  process  are  closed  when  the  process  terminates  or  is  aborted. 

Two  mechanisms  for  a  process  to  initiate  another  process  are  provided: 

a.  Spawn  -  the  procedure  SPAWN _ PROCESS  returns  after  initiating  the  specified  program. 

The  initiating  process  and  the  initiated  process  run  in  parallel,  and,  within  each  of  them, 
their  tasks  may  execute  In  parallel. 

b.  Invoke  -  the  procedure  INVOKE_  PROCESS  returns  control  to  the  calling  task  after  the 
initiated  process  has  terminated  or  aborted.  Execution  of  the  calling  task  is  blocked  until 
termination  or  abortion  of  the  initiated  process,  but  other  tasks  in  the  initiating  process 
may  execute  in  parallel  with  the  initiated  process  and  its  tasks. 

Every  process  node  has  several  predefined  attributes.  Three  of  these  are:  RESULTS,  which  can  be 
used  to  store  user-defined  strings  giving  Intermediate  results  of  the  process;  PARAMETERS,  which 
contains  the  parameters  with  which  the  process  was  initiated:  and  CURRENT _ STATUS,  which  gives 
the  current  status  of  the  process  (see  TARLE  VI).  In  addition,  every  process  node  has  several 
predefined  attributes  which  provide  Information  for  standardized  debugging  and  performance 
measurement  of  processes  within  the  CAIS  Implementation.  One  of  these  predefined  attributes, 
IIANDLES_OPEN.  has  an  implementation-independent  value  which  gives  the  number  of  node 
handles  the  process  currently  has  open.  The  remaining  predefined  attributes  have  implementation- 
dependent  values  and  should  not  be  used  for  comparison  with  values  Trom  other  CAIS 
implementations.  START_TIME  and  FINISH_TIME  give  the  time  of  activation  and  the  time  or 
termination  or  abortion  of  the  process.  MACHINE_TIME  ;ives  the  length  of  time  the  process  was 
active  on  the  logical  processor.  If  the  process  has  terminated  or  aborted,  or  zero,  if  the  process  has  not 
terminated  or  aborted.  IO_UNlTS  gives  the  number  of  CRT  and  PUT  operations  that  have  been 
performed  by  the  process.  The  CURRENT  _  STATUS.  HANDLES,,  OPEN,  START_TIME, 
FINISH_T!ME,  MACHINE_TIME,  and  IO_UNITS  predefined  attributes  are  maintained  by  the 
implementation  and  cannot  be  set  using  CAIS  interfaces. 

When  a  process  has  terminated  or  aborted,  the  final  status,  recorded  in  the  predefined  process  node 
attribute  CURRENT  _STATUS,  will  persist  as  long  as  the  process  node  exists. 
CURRENT_STATUS  may  also  be  examined  by  the  CAIS  procedures  STATE_OF_PROCESS  and 
GET_ RESULTS.  The  process  status  of  a  process  will  be  returned  to  any  task  awaiting  the 
termination  or  abortion  of  the  process  whenever  the  process  is  terminated  or  aborted.  If  the  process 
has  already  been  terminated  or  aborted  at  the  time  a  call  to  AWAIT_PROCESS_COMPLETION  is 
made,  then  the  final  status  is  immediately  available. 

For  purposes  of  input  and  output,  every  process  node  has  one  relationship  of  each  of  the  following 
predefined  relations:  STANI)ARD_  INPUT,  STANDARD_OUTPUT,  STANDARD  _ICRROR. 

CURRENT_  INPUT.  Cl  :R R ENT _ OUTPUT,  and  CURRENT,  ERROR.  STANI)ARD_  INPl  T. 
STANDARD,  OUTPUT  and  STANDARD_ ERROR  are  relation  names  of  relationships  established 
at  job  creation  to  the  default  input,  output  and  error  files,  respectively.  The  STANDARD _ INPUT 
and  STAND. \RD_OUTPUT  files  conform  to  the  semantics  given  Tor  these  in  [LRMj  I  I  d  2. 
CURRENT _ INPUT.  CURRENT  Ol'TPUT  and  Cl 1 R RENT _ ERROR  are  relation  names  of 
relationships  established  by  a  process  to  alternative  files  to  be  used  as  the  default,  input,  output  and 
error  files,  respectively.  CURRENT  _  INPUT  and  CURRENT_OUTPUT  also  conform  to  the 
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semantics  of  [LRM|  14.3.2.  Interfaces  are  provided  in  the  OAIS  input  and  output  packages  (see 
Section  5.3)  to  read  relationships  of  these  predefined  relations  and  to  change  the  relationships  of  the 
relations  CURRENT  INPUT,  CURRENT  OUTPUT,  and  CURRENT  ERROR. 


Table  VI.  Process  status  transition  table 

1  status: 
j  event 

non  existent  1  READY  1  SUSPENDED  1  ABORTED  1  TERMINATED 

'll  II 

1  process 

1  creation 

READY  1  N/A  1  N/A  1  N/A  1  N/A 

II  II 

1  teralnatlon 

1  of  nmln 

1  prograa 

I  TERM-  1  N/A  1  N/A  1  N/A 

N/A  1  INATED  1  1  1 

II  II 

1  ABORT 

N/A 

1  ABOR-  1 

ABORTED 

1  PROCESS 

1  TED  1 

1  SUSPEND 

N/A 

1  SUS-  1 

— 

1  PROCESS 

1  PENDED  1 

1  RESUME 

N/A 

1  -  1 

READY 

1  PROCESS 

1  1 

N/A:  aarks  events  that  are  not  applicable  to  the  status 
specified. 

— :  Marks  events  that  have  no  effect  on  the  status. 

upper  case:  status  which  are  values  of  the  enuaeratlon  type 

PROCESSSTATUS  (e . g . .  READY)  and  for  events  which 
are  caused  by  calling  CAIS  interfaces  (e.g., 
ABORTPROCESS) . 

lower  case:  other  status  (l.e.,  non-existent)  and  other  events 
(e.g.,  teralnatlon  of  the  aaln  program) . 


5.2.1.  Package  PROCESS_DEFINlTIONS 


This  package  defines  the  typos  and  exceptions  associated  with  process  nodes. 

type  PROCESSSTATUS  is 

(READY,  SUSPENDED,  ABORTED.  TERMINATED)  ; 

All  object,  of  typo  PROCESS _ STATUS  is  the  st:i'u>  of  a  process. 

subtype  results_list  is  cais.list  uttlities  . list_type; 
subtype  results_string  is  string, 

subtype  parameter^  ist  is  cais.list_utilities.list_type; 

An  object  of  type  RESULTS _ LIST  is  a  list  of  results  from  a  process.  The  elements  of  this  list  are  of 
type  RHSULTS_STRIN<;.  An  object  of  type  PARAMETER_LIST  is  a  list  containing  process 
parameter  information. 
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ROOTPROCESS 

CURRENT_INFUT 

CURRENt'oUTPUT 

current'error 


constant  namestring 
constant  name_string 
constant  name_string 
constant  name  string 


*  *  CURREKT_ JOB* ; 

•  •CURR£NT~INPVrr* ; 
• 1  CTJRRENT_OUTPUT* 
•'CURRENT  ERROR*; 


ROOT_ PROCKSS  is  a  standard  pathname  for  the  root  process  node  of  the  current  job. 
CURRENT _ INPUT.  CURRENT _ OUTPUT  and  CUi:RENT_ERROR  are  standard  pathnames  for 
the  current  process'  input,  output  and  error  flies,  resp<  <  i ively. 


5.2.2.  Package  PROCESS  CONTROL 

This  package  specifies  interfaces  for  the  creation  and  termination  of  processes  and  examination  and 
modification  of  process  node  attributes. 


As  part  of  the  creation  of  process  nodes,  new  secondary  relationships  are  built  as  described  in  TABLE 
VII. 


Table  VH.  Created  and  inhe  ited  relationships 


A  secondary  relationship  is  created  to  the  node 

of  the  predefined  relation:  Identified  by: 


CURRENT  INPUT 

CURRENTOUTPUT 

CURRENTERROR 

ADOPTED  JtOLE 

CURRENT~NODE 

PARENT 


the  interface  paraaeter  INPUTFILE 
the  interface  paraaeter  OUTPUTFILE 
the  interface  paraaeter  ERRORFILE 
the  interface  paraaeter  FILENODE 
the  Interface  paraaeter  ekvirokkentnode 
the  predefined  constant  currentprocess 
(for  dependent  process  nodes) 
the  predefined  constant  CURRENTUSER 
(for  root  process  nodes) 


The  created  process  node  inherits  all  secondary  relationships 
of  the  following  predefined  relations  froa  the  creating  process 
node: 


CURRENTUSER 

USER 

ALLOW  ACCESS 
DEVICE 

STANDARDINPUT 
STANDARD~OUTPUT 
STAND ARD~ERROR 
ADOPTEDROLE  [1] 
current' job  [a] 


1.  For  CREATE _ JOB,  only  the  relationship  of  the  predefined  relation  ADOPTED _ROLE 
with  the  CUKRENT_USEIl  as  target  is  inherited  from  the  creating  process  node. 

2.  For  CREATE_.IOR,  a  relationship  of  the  predefined  relation  CURRENT _ JOB  is  created 
with  the  new  node  as  both  source  and  target  instead  of  being  inherited  from  the  creating 
process  node. 
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5. 2. 2.1.  Spawning  a  process 

procedure  spawn_process 
(NODE: 

FILE_NOD£ : 
INPUT_PARAMETERS : 
KEY: 

RELATION: 
ACCESS_CONTROL : 
LEVEL:" 
ATTRIBUTES: 
INPUT_FILE: 

OUTPUT _F I LE : 
ERROR_FIL£ : 
ENVIRONMENT  NODE: 


in  out  NODE  TYPE; 
in  NODE -TYPE ; 

in  PARAMETER_LIST:=EMPTY_LIST; 

in  RELATIONSH! P_KEY  :=  LATEST_KEY ; 

in  RELATION_NAME  :=  DEFAULT_RELATION ; 

in  LIST_TYPE  =  EMPTY_LIST;_ 

in  LIST~TYPE  :=  EMPTYLIST; 

in  LIST  TYPE  :=  EMPTYLIST; 

in  NAME~ STRING  :=  CURRENTINPUT; 

in  NAMESTRING  :=  CURRENT^OUTPUT ; 

in  name'string  :=  current'error; 

in  name'string  :=  CURRENT~NODE) ; 


Purpose: 

This  procedure  creates  a  new  process  node  whose  contents  represent  the  execution  of  the 
program  contained  in  the  specified  file  node.  Control  returns  to  the  calling  task  after  the  new 
node  Is  created.  The  process  node  cont  lining  the  calling  task  must  have  execution  rights  for  the 
file  node.  An  open  node  handle  NODE  on  the  new  node  is  relumed,  with  an  intent  ( I  =  > 
READ _ ATTRIBUTES).  The  new  process,  as  a  subject,  has  all  discretionary  access  rights  to  its 
own  process  node  (the  object).  When  the  parent  process  terminates  or  aborts,  the  child  process 
will  be  aborted. 


Secondary  relationships  emanating  from  the  new  process  node  are  created  and  inherited  as 
described  in  TABLE  VI. 


The  ACCESS_CONTROL  parameter  specifies  the  initial  access  control  Information  to  be 
established  for  the  created  node.  If  the  CAIS  models  of  discretionary  and  mandatory  access 
control  are  used,  then,  in  addition  to  the  relationships  established  using  the  information  in  the 
ACCESS_CONTROL  parameter,  an  access  relationship  Is  established  Trom  the  created  process 
node  to  the  current  user  node,  with  a  GRANT  attribute  value  ((READ,  WRITE,  CONTROL)). 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  node  is  to  be  created. 


Parameters: 

NODE  is  a  node  handle  returned  open  on  the  newly  created  process  node. 

KILE_NODE  is  an  open  node  handle  on  the  file  node  containing  the  executable  image  whose 
execution  will  be  represented  by  the  new  process. 

INPUT  _  PARAMETERS 

Is  a  list  containing  proc  -  parameter  Information.  The  list  Is  constructed  and 
parsed  using  the  tools  podded  in  CAIS.LIST_  UTILITIES  (see  Section  5.4).  The 
value  or  INPUT_PARAMKTERS  stored  in  a  predenned  attribute  PARAMETERS 
of  the  new  node. 

KEY  is  the  relationship  key  of  the  primary  relationship  from  the  current  process  node  to 

the  new  process  node.  The  default  is  supplied  by  the  mechanism  of  interpreting  the 
LATEST_  KEY  const  ant. 

RELATION  is  the  relation  name  of  the  primary  relationship  from  the  current  process  node  to 
the  new  process  node.  The  default  is  DEFAI  'LT_ RELATION. 
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ACCESS  _  CONTROL 

is  a  string  defining  the  initial  access  control  Information  associated  with  the  created 
node. 

LEVEL  Is  a  string  defining  the  classification  label  for  the  created  node  (see  TABLE  IV). 

ATTRIBUTES  Is  a  list  which  can  be  used  to  set  attributes  of  the  new  node.  It  could  be  used  by  an 
Implementation  to  establish  allocation  of  resources. 

INPUT  FILE.  OUTPUT _ FILE,  ERROR  _ FILE 
are  pathnames  to  file  nodes. 

ENVIRONMENT  _  NODE 

is  the  node  the  new  process  will  have  as  its  Initial  current  node.  The  default  value 
is  the  CURRENT  _  NODE  of  the  Initiating  process. 


Exceptions: 

NAME  _  ERROR 

Is  raised  if  a  node  already  exists  for  thp  relationship  specified  by  KEY  and 
RELATION.  NAME_ ERROR  is  also  raised  If  any  of  the  nodes  Identified  by 
INPUT  _  FILE,  OUTPl IT _ FILE,  ERROR_FILE,  or  ENVIRONMENT _ NODE  do 
not  exist.  It  is  also  raised  if  KEY  or  RELATION  Is  syntactically  illegal  or  if  any 
node  identifying  a  group  specified  In  the  given  ACCESS_ CONTROL  parameter  is 
unobtainable  or  Inaccessible. 

USE_ERROR  Is  raised  if  It  can  be  determined  that  the  node  Indicated  by  FILE_NODE  does  not 
contain  an  executable  Image.  USE_ ERROR  is  also  raised  ir  any  of  the  parameters 
INPUT _ PARAMETERS,  LEVEL,  ACCESS_CONTROL.  or  ATTRIBUTES  is 
syntactically  or  semantically  illegal.  USE_  ERROR  Is  also  raised  If  RELATION  is 
the  name  of  a  predefined  relation  or  if  the  ATTRIBUTES  parameter  contains 
references  to  a  predefined  attribute  which  cannot  be  modified  or  created  by  the 
user. 

STATUS _ ERROR 

is  raised  if  NODE  is  an  open  node  handle  prior  to  the  call  or  if  FILK_NOI)E  is  not 
an  open  node  handle. 

LOCK  _  ERROR 

is  raised  if  access  with  intent  APPEND  _  RELATIONSHIPS  to  the  current  process 
node  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

INTENT  _  VIOLATION 

is  raised  if  the  node  designated  by  FILE_NODE  was  not  opened  with  an  inteni 
establishing  the  right  to  execute  its  contents. 


Notes: 

SPAWN  PROCESS  does  not  return  results  or  process  status.  If  coordination  between  any  task 
and  the  new  process  is  desired,  AWAIT  _  PROCESS_COMPI,KTION  or  the  toehni<|ues 
provided  in  CAIS  input  and  output  (see  Section  5..I)  must  bo  used. 
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5. 2. 2. 2.  Awaiting  termination  or  abortion  of  another  process 

procedure  await  process  completion 

(NODE:  in  NODE_TYPE ; 

TIME_LI«IT:  in  DURATION  :=  DURATION ’LAST) ; 

Purpose: 

This  procedure  suspends  the  calling  task  and  waits  for  the  process  Identified  by  NODI5  to 
terminate  or  abort.  The  calling  task  is  suspended  until  the  identified  process  terminates  or 
aborts  or  until  the  time  limit  is  exceeded. 

Parameters: 

NODE  is  an  open  node  handle  for  the  process  to  be  awaited. 

TIME_ LIMIT  Is  the  limit  on  the  time  that  the  calling  task  will  be  suspended  awaiting  the  process. 

When  the  limit  Is  exceeded  the  calling  task  resumes  execution.  The  default  Is  the 
implementation-dependent  maximum  value  for  DURATION. 


Exceptions: 

NAME_  ERROR 

is  raised  if  the  node  identified  by  NODE  is  inaccessible  or  unobtainable. 

STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 

INTENT  _ VIOLATION 

Is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
attributes. 


Additional  interface: 

procedure  awaitprocesscompletion 

(NODE-  "  :  in  NODE  TYPE; 

RESULTS_RETURNED  :  in  out  RESUL.TS  LIST; 

STATUS  OUt  PROCESS  STATUS; 

TIME_LIMIT  :  in  DURATION-  :=  DURATION  ’ LAST) 

is 

begin 

AWAIT_PROCESS_COMPLETION  (NODE,  TIME_LINIT) ; 

GET_RESULTS  (NODE,  RESULTS  RETURNED) 7 
STATUS  :=  STATUS_OF_PROCES§  (NODE); 
end  AWAIT  PROCESS  COMPLETION; 


5. 2. 2. 3.  Invoking  a  new  process 
procedure  invoke  process 


(NODE : 

in 

out  NODE_TYPE; 

FILE_NODE : 

in 

NODE_TYPE ; 

R£SULTS_RE TURNED : 

in 

OUt  RESULTS; 

STATUS : _ 

OUt  PROCESS_STATUS ; 

INPUTPARAMETERS: 

in 

PARAMETERLIST; 

KEY' 

in 

RELATIONSHIPKEY  :=  LATESTKEY; 

RELATION : 

in 

RELATION  NAME : =DEF AULT  RELATION; 

H.r> 
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ACCESS_CONTROL :  in  LIST_TYPB  :=  EMPTY J.ZST; 

LEVEL:-  in  LIST-TYPE  :=  EMPTYJ.IST; 

ATTRIBUTES:  in  LISTJTYPE  :=  EWPTY_LIST; 

INPUT_FILE:  in  NAME~STRIHG  :=  CURRENT_INFUT ; 

OUTPUTFILE:  in  NAVE~STRING  :=  CURRENTJJUTPUT ; 

ERRQRFILE:  in  NAJrtfsTRING  :=  CTJRREKT~ERRQR ; 

ENVIRONMENT_NODE :  in  NAMESTRING  :=  CURREKT~KODE ; 

TIME_LIMIT:  in  DURATION  :=  DURATION 'LAST) ; 

Purpose: 

This  procedure  provides  the  functionality  described  by  the  following  Ada  fragment  except  that 
the  Implementation  must  guarantee  that  only  exceptions  raised  by  the  call  to 
SPAWN _ PROCESS  In  this  fragment  are  raised  by  INVOKE _  PROCESS. 

SPAWN  PROCESS  (NODE.  FILE_NODE.  INPUT_PARAMETERS .  KEY.  RELATION. 

ACCESS_CONTROL ,  LEVEL . "ATTRIBUTES .  INPUT_FILE. 

OUTPUT~FILE,  ERRORFILE,  ENVIRONWENTNODE) ; 

AWAIT  PROCESSCOMPLETION  (NODE,  TINELIVIT) ; 

GETRESULTS  (NODE.  RESULTSRETURNED) 7 
STATUS  :=  STATOSOFPROCESi  (NODE); 

Parameters: 

NODE  is  a  node  handle  returned  open  on  the  newly  created  process  node. 

FII,E_NODE  Is  an  open  node  handle  on  the  file  node  containing  the  executable  Image  whose 
execution  will  be  represented  by  the  new  process. 

RESULTS  _  RETURNED 

Is  a  list  of  results  which  are  represented  by  strings  from  the  new  process.  The 
Individual  results  may  be  extracted  from  the  list  using  the  tools  of 
CAIS. LIST  _  UTILITIES. 

STATUS  gives  the  process  status  of  the  process.  If  termination  or  abortion  of  the  Identified 
process  can  be  reported  within  the  specified  time  limit,  STATUS  will  have  the  value 
ABORTED  or  TERMINATED.  If  the  process  does  not  terminate  or  abort  within 
the  time  limit,  STATUS  will  have  the  value  READY  or  SUSPENDED. 

INPUT  _  PARAMETERS 

Is  a  list  containing  process  parameter  Information.  The  list  Is  constructed  and 
parsed  using  the  list  handling  tools  of  CA!S.LIST_ UTILITIES.  The  value  of 
INPUT  _  PARAMETERS  is  stored  In  the  predefined  attribute  PARAMETERS  of 
the  new  node. 

KEY  is  the  relationship  key  of  the  primary  relationship  from  the  current  process  node  to 

the  new  process  node.  The  default  is  supplied  by  the  mechanism  -  nterpreting  the 
LATEST _ KEY  constant. 

RELATION  is  the  relation  name  of  the  primary  relationship  from  the  current  process  node  to 
the  new  node.  The  default  Is  DEFAULT _  RELATION. 

ACCESS  _CONTROI, 

Is  a  string  defining  the  initial  access  control  information  associated  with  the  created 
node. 

LEVEL  is  a  string  defining  the  classification  label  for  lie  created  node  (sec  TABLE  IV!. 
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ATTRIBUTES  Is  a  list  which  can  he  used  to  set  attributes  of  the  new  node,  ft  could  be  used  by  an 
implementation  to  establish  allocation  of  resources. 

INPUT  FILE,  OUTPUT  FILE.  ERROR_FILE 
are  pathnames  to  file  nodes. 

ENVIRONMENT  _  NODE 

Is  the  node  the  -ew  process  will  have  as  its  current  node. 

TIME_LIMIT  is  the  limit  on  the  time  that  the  calling  task  will  be  suspended  awaiting  the  new 
process.  When  the  limit  Is  exceeded,  the  calling  task  resumes  execution.  The 
default  is  the  implementation  dependent  maximum  value  for  DURATION. 

Exceptions: 

NAME  _  ERROR 

Is  raised  If  a  node  already  exists  for  the  relationship  specified  by  KEY  and 
RELATION.  NAME_  ERROR  is  also  raised  if  any  of  the  nodes  identified  by 
INPUT_FJLE.  OUTPUT_  FILE,  ERROR _  FILE  or  ENVIRONMENT  NODE  do 
not  exist.  It  Is  also  raised  if  KEY  or  RELATION  is  syntactically  illegal  or  if  any 
node  identifying  a  group  specified  in  the  given  ACCESS_CONTROL  parameter  Is 
unobtainable  or  inaccessible. 

USK_ERROR  is  raised  If  It  can  be  determined  that  the  node  Indicated  by  FILE_NODE  does  not 
contain  an  executable  image.  USE_ ERROR  is  also  raised  if  any  of  the  parameters 
INPUT _ PARAMETERS,  LEVEL,  ACCESS  _CONTROL,  or  ATTRf MUTES  is 
syntactically  or  semantically  illegal.  USE_ ERROR  is  also  raised  if  RELATION  is 
the  name  of  a  predefined  relation  or  if  the  ATTRIBUTES  parameter  contains 
references  to  a  predefined  attribute  which  cannot  be  modified  or  created  by  the 
user. 

STATUS _ ERROR 

is  raised  if  NODE  is  an  open  node  handle  prior  to  the  call  or  If  FILE_NODE  is  not 
an  open  node  handle. 

LOCK  ERROR 

Is  raised  If  access  with  Intent  APPEND_RELAT!ONSIIIPS  cannot  be  obtained  to 
the  current  process  node  due  to  an  existing  lock  on  the  node. 

INTENT  _  VIOLATION 

Is  raised  If  the  node  designated  by  FILE_NODE  was  not  opened  with  an  Intent 
establishing  the  right  to  execute  contents. 


Notes: 

Both  control  and  data  (results  and  status)  are  returned  to  the  calling  task  upon  termination  or 
abortion  of  the  invoked  process  or  when  the  TIME_LIMIT  Is  exceeded. 
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5. 2.2.4.  Creating  a  new  job 

procedure  create_job 


(FIL£_NODE : 

in 

NODE_TYPE; 

INPUT_PARAMETERS : 

in 

PARAMETER_LIST: =EMPTY_LIST; 

KEY : 

in 

RELATI ONSHI P_KEY  :=  LATEST_KEY ; 

ACCESSCONTROL : 

in 

LIST_TYPE  :=”EMPTY_LIST; 

LEVEL:” 

in 

LISTjrYPE  :=  EMPTy”lIST; 

ATTRIBUTES: 

in 

LISTJTYPE  :  =  EMPTY_LIST; 

INPUT_FILE : 

in 

NAMESTRING  :=  CURRENT_  INPUT; 

OUTPUT_FILE: 

in 

NAMe”sTRING  :=  CURRENT_OUTPUT; 

ERROR  FILE: 

in 

NAMESTRING  :=  OJRRENTERROR ; 

ENVIRONMENT  NOPE: 

in 

NAMe’sTRING  :=  CURRENT  USER); 

Purpose: 

This  procedure  creates  a  new  root  process  node  whose  contents  represent  the  execution  of  the 
program  contained  in  the  specified  file  node.  Control  returns  to  the  calling  task  after  the  new 
job  is  created.  The  process  node  containing  the  calling  task  must  have  execution  rights  for  the 
file  node  and  sufficient  rights  to  append  relationships  to  the  node  identified  by 
"'CURRENT_USER".  A  new  primary  relationship  of  the  predefined  relation  JOB  Is 
established  from  the  current  user  node  to  the  root  process  node  of  the  new  Job.  The  new  root 

process  as  a  subject  can  acquire  all  discretionary  access  rights  to  Its  own  process  node  (the 

object).  Secondary  relationships  emanating  from  the  new  process  node  are  created  and  Inherited 
as  described  In  TABLE  VI. 

The  ACCESS_CONTROL  parameter  specifies  the  initial  access  control  Information  to  be 
established  for  the  created  node.  If  the  CAIS  models  or  discretionary  and  mandatory  access 

control  are  used,  then.  In  addition  to  the  relationships  established  using  the  information  In  the 

ACCESS _ CONTROL  parameter,  an  access  relationship  Is  established  from  the  created  process 
node  to  the  current  user  node,  with  a  GRANT  attribute  value  ((READ,  WRITE,  CONTROL)). 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  node  Is  to  be  created. 

Parameters: 

FILE_NOI)E  is  an  open  node  handle  on  (he  file  node  containing  the  executable  image  whose 
execution  will  be  represented  by  the  new  process. 

INPUT  PARAMETERS 

is  a  list  containing  process  parameter  information.  The  list  Is  constructed  and 
parsed  using  the  tools  provided  in  CAIS.LIST_  UTILITIES. 
INPUT _  PARAMETERS  is  stored  in  the  predefined  attribute  PARAMETERS  of 
the  new  node. 

KEY  is  the  relationship  key  of  the  primary  relationship  of  the  predefined  relation  JOB 

from  the  current  user  node  to  the  new  process  node.  The  default  Is  supplied  by  the 
mechanism  of  interpreting  the  LATEST _ KEY  constant. 

AC( '  ESS  _  CONTROL 

is  a  string  defining  the  Iniilal  access  control  Information  associated  with  the  created 
node. 


LEVEL  is  a  string  defining  the  classification  label  for  the  created  node  (see  TABLE  IV). 
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ATTRIBUTES  is  a  list  which  can  be  used  to  set  attributes  of  the  new  node.  It  could  be  used  by  an 
implementation  to  establish  allocation  of  resources. 

INPUT_FILE.  OUTPUT  _FILE,  ERROR_FII.E 
are  pathnames  to  file  nodes. 

ENVIRONMENT  NODE 

is  the  node  the  new  process  will  have  as  its  initial  current  node. 


Exceptions: 

NAME  _  ERROR 

Is  raised  if  a  node  already  exists  for  the  relationship  specified  by  KEY  and  the 
relation  JOB.  NAME_ ERROR  is  also  raised  If  any  of  the  nodes  identified  by 
INPUT_FILE,  OUTPUT _ FILE.  ERROR _ FILE  or  ENVIRONMENT  NODE  does 
not  exist.  It  is  also  raised  if  KEY  is  syntactically  illegal  or  if  any  node  identifying  a 
group  specified  in  the  ACCESS  _  CONTROL  parameter  is  unobtainable  or 
Inaccessible. 

USK_ERROR  is  raised  if  it  can  be  determined  that  the  node  indicated  by  F(LE_NODE  does  not 
contain  an  executable  image.  USE_ ERROR  is  also  raised  iT  any  of  the  parameters 
INPUT  PARAMETERS,  LEVEL.  ACCESS_CONTROL,  or  ATTRIBUTES  is 
syntactically  or  semantically  illegal.  USE _ ERROR  Is  also  raised  If  the 
ATTRIBUTES  parameter  contains  references  to  a  predefined  attribute  which 
cannot  be  modified  or  created  by  the  user. 

STATUS _ ERROR 

is  raised  if  FILE_NODE  is  not  an  open  node  handle. 

LOOK  _  ERROR 

is  raised  if  access  to  'he  current  user  node  or  the  current  process  node  with  Intent 
APPEND _  RELATIONSHIPS  cannot  be  obtained  due  to  an  existing  lock  on  the 
node. 

INTENT_  VIOLATION 

is  raised  if  the  node  designated  by  FILE_NODE  was  not  opened  with  an  Intent 
establishing  the  right  to  execute  contents. 

ACCESS  _  VIOLATION 

is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  rights  to 
open  the  current  user  node  with  APPEND_  RELATIONSHIPS  intent. 
ACCESS _ VIOLATION  is  raised  only  if  the  conditions  for  raising  NAME_ERROR 
are  not  satisfied. 

SE<  l  'RITY  _  VIOLATION 

is  raised  if  the  attempt  to  obtain  access  to  the  node  Identified  by 
CURRENT_USER  represents  a  violation  of  mandatory  access  controls  for  the 
CAIS.  SECURITY _ VIOLATION  is  raised  only  if  the  conditions  for  raising  the 
other  exceptions  are  not  satisfied. 


Notes: 


HO 
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CREATE_JOB  does  not  return  results  or  process  si  itus  to  the  calling  program  unit.  If 
coordination  between  any  program  unit  and  the  new  process  is  desired, 
AWAIT_PROCESS_COMPLETION  or  th-  techniques  provided  In  CAIS  input  and  output 
(see  Section  5.3)  must  be  used. 

The  relation  name  for  the  primary  relationship  to  the  new  node  is  JOB. 

5. 2.2.5.  Appending  reaulta 

procedure  append_results  (results  :  in  results_string)  ; 


Purpose: 

This  procedure  inserts  the  value  of  its  RESULTS  parameter  as  the  last  item  in  to  the  list  which 
is  the  value  of  the  RESULTS  attribute  of  the  current  process  nod* 

Parameters: 


RESULTS  is  a  string  to  be  appended  to  the  RESULTS  attribute  value  of  the  <  urrent  process 
node. 


Exceptions: 

LOCK  _  ERROR 

Is  raised  if  access  with  intent  WRITE _ ATTRIBUTES  to  the  current  process  node 
cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

5. 2.2.8.  Overwriting  reaulta 

procedure  writeresults  (results:  in  results  string)  ; 


Purpose: 

This  procedure  replaces  the  value  of  the  RESULTS  attribute  of  the  current  process  nodp  with  a 
list  containing  a  single  Item  which  Is  the  value  of  the  parameter  RESULTS. 

Parameters: 

RESULTS  is  a  string  to  be  stored  In  the  RESULTS  attribute  of  the  current  process  node. 


Exceptions: 


LOOK _ ERROR 

Is  raised  if  access  with  Intent  WRITE_ ATTRIBUTES  to  the  current  process  node 
cannot  be  obtained  due  to  an  existing  lock  on  the  node. 


5. 2. 2.7.  Getting  results  from  a  process 

procedure  get_results (node :  in  nodejtype; 

RESULTS  :  in  Out  RESULTS  LIST )  ; 


Purpose: 

This  procedure  returns  the  value  of  the  attribute  RESULTS  of  the  process  node  identified  by 
NODE.  The  process  need  not  have  terminated  or  aborted.  The  empty  list  is  returned  in 
RESULTS  if  WRITE _ RESULTS  or  AITENI)_RESULTS  has  not  been  called  by  the  process 
contained  In  the  node  Identified  by  NODI',. 
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Parameters: 

NODI')  is  an  open  node  handle  on  a  process  node. 

RKSULTS  is  an  unnamed  list  of  strings  which  returns  the  value  of  the  RESULTS  attribute  of 

the  process  node  identified  bv  NODE.  The  individual  strings  may  be  extracted 
from  the  list  using  the  tools  of  CAIS.LIST_ UTILITIES  (see  Section  5.4). 

Exceptions: 

USE_  ERROR  is  raised  if  the  node  identified  by  NODE  is  not  a  process  node. 

STATUS _ ERROR 

is  raised  if  NODE  is  not  an  op<  n  node  handle. 

INTENT_  VIOLATION 

is  raised  if  the  NODE  was  not  opened  with  an  intent  establishing  the  right  to  read 
attributes. 


Additional  Interfaces: 

procedure  get  results  (node :  in  nodejiype; 

RESULTS:  in  OUt  RESULTSLIST; 
STATUS:  out  PROCESSSTATUS) 

is 

begin 

GET  RESULTS  (NODE.  RESULTS); 

STATUS : =STATUS_0F  PROCESS (NODE) ; 
end  GETRESULTS ;  “ 

procedure  get  results  (name  .  in  namestring; 

RESULTS:  in  out  RESULTS  LIST; 
STATUS :  OUt  PROCESS  STATUS) 

is 

NODE:  NODE  TYPE; 
begin 

OPEN (NODE.  NAME.  (1=>READ_ATTRIBUTES) ) ; 

GETRESULTS (NODE ,  RESULTS ) ; 

STATUS : =STATUS_OF_PROCESS (NODE) ; 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  GET  RESULTS; 

procedure  get  results (name :  in  name  string; 

RESULTS:  in  out  RESULTS  LIST) 

is 

NODE:  NODEJIYPE; 
begin 

OPEN (NODE .  NAME.  (1=>READ_ATTRIB  ES)); 

GET_RESULTS (NODE ,  RESULTS): 

CLOSE (NODE) : 

exception 

when  others  => 

CLOSE (NODE) ; 

raise; 

end  GET  RESULTS; 
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5. 2. 2. 8.  Determining  the  status  of  a  process 

function  status jofjprocess  (node  :  in  node_type) 
return  process  status; 


Purpose: 

This  function  returns  the  current  status  of  the  process  represented  by  NODE.  It  returns  the 
value  of  the  attribute  CURRENT  _STATU-'  associated  with  the  process  node  identified  by 
NODE. 

Parameters: 

NODE  is  an  open  node  handle  Identifying  the  node  of  the  process  whose  status  is  to  be 

queried. 


Exceptions: 

USE  ERROR  is  raised  if  the  node  Identified  by  NODE  is  not  a  process  node. 


STATUS  _  ERROR 

Is  raised  if  NODE  is  not  an  open  node  handle. 


INTENT_  VIOLATION 

Is  raised  If  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  attributes. 


Additional  Interface: 

function  statusof  process (NAME:  in  hakestring) 
return  processstatus 

is 

MODE:  NODETYPE; 

RESULT:  PROCESSSTATUS ; 

begin 

OPEN (NODE .  NAME.  (1=>READ_ATTRIBUTES) ) ; 

RESULT  :=  STATUS  OF_PROCESS(NODE) ; 

CLOSE (MODE); 
return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  status  of  process; 


5. 2. 2.9.  Getting  the  parameter  list 

procedure  get_parameters  (parameters  :  in  out  parameter  list)  ; 

Purpose: 

This  procedure  returns  the  value  of  the  predefined  attribute  PARAMETERS  of  the  current 
process  node. 

Parameters: 

PARAMETERS 
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Is  a  list  containing  parameter  information.  The  list  Is  const  meted  and  can  be 
manipulated  using  the  tools  provided  in  CAJS.LIST_UTILITIEN 


Exceptions: 

LOCK  _  ERROR 

is  raised  if  access  with  intent  READ_  ATTRIBUTES  to  the  i  urrent  process  node 
cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

Notes: 

The  value  of  the  predefined  attribute  PARAMETERS  is  set  during  process  node  creation;  see 
the  interfaces  SPAWN _ PROCESS.  INVOKE_ PROCESS  and  CREATE _  JOB. 

5.2.2.10.  Aborting  a  process 

procedure  ABORT  PROCESS  (NODE:  in  NODETYPE; 

RESULTS:  in  RESULTS  STRING); 


Purpose: 

This  procedure  aborts  the  process  represented  by  NODE  and  forces  any  processes  in  the  subtree 
rooted  at  the  identified  process  to  be  aborted.  The  order  of  the  process  abortions  is  not 
specified.  If  the  state  of  the  process  represented  by  NODE  after  return  of  ABORT  _ PROCESS 
is  examined,  It  will  be  ABORTED  or  TERMINATED;  It  will  be  TERMINATED  only  ir  the 
process  terminated  before  ABORT _ PROCESS  took  effect.  The  node  associated  with  the 
aborted  process  remains  until  explicitly  deleted.  If  an  exception  is  raised,  none  of  the  processes 
are  aborted. 

Parameters: 

NODE  is  an  open  node  handle  for  the  node  of  the  process  to  be  aborted. 

RESULTS  is  a  string  to  be  appended  to  the  RESULTS  attribute  of  the  node  represented  by 

NODE. 

Exeeptlons: 

USE_ERROR  Is  raised  If  the  node  identified  by  NODE  Is  not  a  process  node. 

STATUS  ERROR 

Is  raised  if  NODE  is  not  an  open  node  handle. 

INTENT_  VIOLATION 

Is  raised  if  the  node  was  not  opened  with  an  intent  establishing  rights  to  read 
relationships  and  to  write  attributes  and  contents. 

ACCESS  _  VIOLATION 

Is  raised  If  the  current  proeess  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  any  node  of  a  process  to  be  aborted  with  intent  including 
READ  RELATIONSIIIPS.  WRITI  ATTRIBUTES  and  WRITE_(  ONTENTS. 

SECURITY_ VIOLATION 

is  raised  If  the  attempt  to  obtain  n<  css  to  the  node  identified  by  NODE  represents 
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a  violation  of  mandatory  access  controls  In  the  CAIS.  SBCURITY_ VIOLATION  is 
raised  only  If  the  conditions  for  raising  the  other  exceptions  are  not  satisfied. 


Additional  Interfaces: 

procedure  abort_process (name :  in  name  string; 

RESULTS:  in  RESULTS_STR I NG) 

is 

NODE:  NODE  TYPE; 
begin 

OPEN (NODE,  NAME,  (READ  RELATIONSHIPS,  WRITE_CONTENTS , 

WRITE_ATTRIBUTES) > ; 

ABORT_PROCESS (NODE .  RESULTS); 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  ABORTPROCESS ; 

procedure  abort_process  (node  :  in  node_type) 

is 

begin 

ABORT_PROCESS(NODE. 'ABORTED') ; 
end  ABORT  PROCESS; 

procedure  abortprocess  (name  :  in  name  string) 

is 

NODE:  NODETYPE; 
begin 

OPEN (NODE,  NAME.  (READRELATIONSHIPS, WRITE_CONTENTS. WRITE  ATTRIBUTES) ) ; 
ABORT  PROCESS (NODE . 'ABORTED' ) ; 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (NOOE) ; 
raise; 

end  ABORT  PROCESS; 


Notes: 

ARORT_ PROCESS  can  be  used  by  a  task  to  abort  the  process  that  contains  it.  It  is 
intentional  that  LOCK _ ERROR  will  not  be  raised  by  this  procedure. 


5.2.2.11.  Suspending  a  process 

procedure  suspend_process(node:  in  node_type)  ; 


Purpose: 

This  procedure  suspends  the  process  represented  by  NODE.  After  SUSPEND _ PROCESS  Is 
called,  the  CURRENT _ST ATI'S  of  the  Identified  process  Is  SUSPENDED,  provided  that  the 
process  wn  in  the  READY'  status  at  the  time  that  the  suspension  look  effect. 
SUSPKND_PROCESS  does  not  change  the  process  status  If  the  process  Is  not  In  the  READY' 
state.  If  the  node  Identified  by  NOPE  Is  the  parcnl  of  other  process  nodes,  the  other  processes 
are  likewise  suspended  if  an  exception  Is  raised,  none  of  tile  processes  are  suspc  ded. 


Parameters: 

NODE  Is  an  open  node  handle  Identifying  the  node  of  the  process  to  be  suspended 

Page  3-168 


91 


PROPOSED  \lll,-»TI>-<  \l» 
31  J  \M  !*)«-, 


Exceptions: 

USE _ ERROR  is  raised  if  the  node  identified  by  NODE  is  not  a  process  node. 

STATUS_ ERROR 

Is  raised  If  NODE  is  not  an  open  node  handle. 

INTENT  _  VIOLATION 

is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  rights 
to  read  relationships  and  to  write  attributes  and  contents. 

ACCESS  _  VIOLATION 

Is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  rights  to 
obtain  access  to  any  node  of  a  process  to  be  suspended  with  intent  including 
READ _ RELATIONSHIPS,  WRITE __  ATTRIBUTES  and  WRITE _ CONTENTS. 

SECURITY_  VIOLATION 

is  raised  if  the  attempt  to  obtain  access  to  the  node  identified  by  NODE  represents 
a  violation  of  the  mandatory  access  controls  for  the  CAIS. 
SECURITY _ VIOLATION  Is  raised  only  if  conditions  for  raising  the  other 
exceptions  are  not  satisfied. 

Additional  Interface: 

procedure  suspend  process  (name  :  in  name_string) 

is 

NODE:  NODETYPE; 
begin 

OPEN (NODE.  NAME.  (READ  RELATIONSHIPS,  WRITE_ATTRIBUTES. 

WRITECONTENTS) ) ; 

SUSPENDPROCESS (NODE) ; 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise: 

end  suspend  process; 


Notes: 

SUSPEND  _ PROCESS  can  be  used  by  a  task  to  suspend  the  process  that  contains  it. 

5.2.2.12.  Resuming  a  process 

procedure  resume_process(node.  in  node_type)  ; 


Purpose: 

This  procedure  causes  the  process  represented  by  NODE  to  resume  execution. 
RESUME_  PROCESS  does  not  change  the  process  status  if  the  process  is  not  suspended.  After 
RES!  'ME  _  PROCESS  is  called,  the  PROCESS  _  ST  ATI 'S  or  the  Identified  process  is  READY 
provided  that  the  process  was  In  the  SUSPENDED  status  at  the  lime  that  the  resumption  took 
effect.  If  the  node  Identified  by  NODE  Is  the  parent  of  other  process  nodes,  the  other  processes 
are  likewise  resumed.  If  an  exception  Is  raised,  none  of  I  he  processes  Is  resumed. 


Parameters: 
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NODE  is  an  open  node  handle  identifying  the  node  of  the  process  to  be  resumed. 


Exceptions: 

USE_ ERROR  Is  raised  if  the  node  identified  by  NODE  Is  not  a  process  node. 

STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 

INTENT  VIOLATION 

Is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  rights 
to  read  relationships  and  to  write  attributes  and  contents. 

ACCESS  _  VIOLATION 

Is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  rights  to 
obtain  access  to  any  node  of  a  process  to  be  suspended  with  Intent  including 
READ _ RELATIONSHIPS.  WRITE _  ATTRIBUTES  and  WRITE _ CONTENTS. 

SECURITY_  VIOLATION 

is  raised  If  the  attempt  to  obtain  access  to  the  node  identified  by  NODE  represents 
a  violation  of  the  mandatory  access  controls  for  the  CAJS. 
SECURITY _ VIOLATION  Is  raised  only  if  the  conditions  for  raising  the  other 
exceptions  are  not  satisfied. 


Additional  Interface: 

procedure  resumeprocess  (hake  :  in  mamestrimg) 

is 

MODE:  MODE  TYPE; 
begin 

OPEN  (NODE .  MANE,  (READRELATIONSHIPS,  MRITEATTRIBUTES. 

NRITECOMTENTS) ) ; 

RESUMEPROCESS (MODE) ; 

CLOSE (MODE) ; 
exception 

when  others  => 

CLOSE (MODE) ; 
raise: 

end  resume  process; 


5.2.2.13.  Determining  the  number  of  open  node  handles 

function  hamdlesopen  (mode  :  in  mode  type) 
return  natural; 


Purpose: 

This  function  returns  a  natural  number  representing  the  value  of  the  predefined  attribute 
HANDLES  _OPEN  of  the  process  node  Identified  by  NODE. 


Parameters: 

NODE  is  an  open  node  handle  Identifying  the  proees.s  node  whose  attribute  is  being 

queried. 
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Exceptions: 

USE _  ERROR  Is  raised  if  the  node  identified  by  NODE  is  not  a  process  node. 
STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 


INTENT  _  VIOLATION 

is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  attributes. 


Additional  Interface: 

function  handles_open  (name  .  in  namestring) 
return  natural 

is 

NODE:  NODETTPE; 

RESULT:  NATURAL; 
begin 

OPEN (NODE.  NAME.  (1=>READ_ATTRIBUTES) ) ; 
RESULT  :=  HANDLESOPEN (NODE) ; 

CLOSE (NODE) ; 

return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise; 

end  HANDLES  OPEN; 


5.2.2.14.  Determining  the  number  of  input  and  output  units  used 

function  iounits  (node  :  in  node  type) 
return  natural; 


Purpose: 

This  function  returns  a  natural  number  representing  the  value  of  the  predefined  attribute 
f()_  UNITS  of  the  process  node  ideii'iDed  by  NODE. 


Parameters: 

NODE  is  an  open  node  handle  identifying  the  process  node  whose  attribute  is  being 

queried. 


Exceptions: 

USE_  ERROR  is  raised  if  the  node  identified  by  NODE  is  not  a  process  node. 


STATUS _ ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 

DOCK  _ ERROR 

is  raiseil  if  the  node  is  locked  against  reading  attributes. 
INTENT  VIOLATION 
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is  raised  If  the  node  handle  was  not  opened  with  an  intent  establishing  the  right  to 
read  attributes. 


Additional  Interface: 

function  io_units  (name  .  in  namestring) 
return  natural 

i  a 

NODE;  NODE_TYPE; 

RESULT:  NATURAL; 
begin 

OPEN (NODE,  NAME,  (1=>READ_ATTRIBUTES) ) ; 
RESULT  :=  IO_UNITS(NODE) ; 

CLOSE (NODE) ; 

return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 

raise; 

end  io  UNITS; 


5.2.2.15.  Determining  the  time  of  activation 

function  starttime  (node  :  in  nodetype) 
return  TIME; 


Purpose: 

This  function  returns  a  value  of  type  TIME  representing  the  value  of  the  predefined  attribute 
START _ TIME  of  the  process  node  identified  by  NODE. 


Parameters: 

NODE  Is  an  open  node  handle  Identifying  the  process  node  whose  attribute  Is  being 

queried. 


Exceptions: 

USE  ERROR  is  raised  if  the  node  Identified  by  NODE  is  not  a  proeess  node. 


STATUS _ ERROR 

Is  raised  if  NODE  is  not  an  open  node  handle. 

LOCK  _  ERROR 

is  raised  if  the  node  is  locked  against  reading  attributes. 

INTENT  _  VIOLATION 

is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  attributes. 


Additional  Interface: 

function  start  time  (name  :  in  name  string) 
return  time 

is 

NODE:  NODE  TYPE; 
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RESULT:  TIME; 

begin 

OPEN (NODE ,  NAME,  (1=>READ_AT  RIBUTES) ) ; 
RESULT  : =  START_TIME (NODE) ; 

CLOSE (NODE) ; 

return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise ; 

end  START  TIME; 


5.2.2.10.  Determining  the  time  of  termination  or  abortion 

function  finish  time  (node  :  in  node  type) 
return  time; 


Purpose: 

This  function  returns  a  value  of  type  TIME  representing  the  value  of  the  predefined  attribute 
FINISH _ TIME  of  the  process  node  identified  by  NODE. 


Parameters: 

NODE  Is  an  open  node  handle  identifying  the  process  node  whose  attribute  is  being 

queried. 


Exceptions; 

USE_ ERROR  Is  raised  if  the  node  Identified  by  NODE  Is  not  a  process  node. 


STATUS  ERROR 

is  raised  if  NODE  is  not  an  open  node  handle. 


INTENT  _  VIOLATION 

is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  attributes. 


Additional  Interface: 

function  finish  time  (name  :  in  name_string) 
return  time 

is 

NODE:  N0DE_TYPE ; 

RESULT:  TIME; 

begin 

OPEN (NODE ,  NAME,  (1 =>READ_ATTRIBUTES) ) ; 
RESULT  :=  FINISHTIME (NODE) ; 

CLOSE (NODE) ; 

return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 

raise; 

end  FINISH  TIME; 
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5.2.2.17.  Determining  the  time  a  process  has  been  active 

function  machine_time  (node  :  in  node_ttpe) 
return  duration; 


Purpose: 

This  function  returns  a  value  of  type  D(  ORATION  representing  the  value  of  the  predefined 
attribute  MACHINE  TIME  of  the  process  nodi-  identified  by  NODE. 


Parameters; 

NODE  is  an  open  node  handle  identifying  the  process  node  whose  attribute  is  being 

queried. 


Exceptions: 

USE_ERROR  is  raised  if  the  node  identified  by  NODE  is  not  a  process  node. 
STATUS _ ERROR 

Is  raised  If  NODE  Is  not  an  open  node  handle. 


INTENT  _  VIOLATION 

is  raised  if  the  node  handle  NODE  was  not  opened  with  an  intent  establishing  the 
right  to  read  attributes. 


Additional  Interface; 

function  machine_time  (name  in  hamz  stmkg) 
return  duration 

is 

NODE:  NODE  TYPE; 

RESULT.  DURATION; 

begin 

OPEN (NODE,  NAME.  (1=>READ_ATTRIBUTES) ) ; 
RESULT  :*  MACHINE  TIME (NODE) ; 

CLOSE  (NODE); 
return  result; 
exception 

when  others  => 

CLOSE (NODE) ; 
raise: 

end  machine  TIME; 


5.3.  CAIS  input  and  output 

The  CAIS  defines  four  kinds  of  flies:  secondary  storage  files,  queue  flies,  terminal  flies  and  magnetic 
tape  drive  flies.  CAIS  flies  are  supported  by  CAIS  input  and  output  packages  as  descrtbcd  in  TABLE 
VIII. 
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Table  VIII.  Inpul  and  output  packages  for  file  kinds 


Secondary 

Storage 

Queue 

Terminal 

Magnetic 

Tape 

CAIS. 10  CONTROL 

1 

X 

1 

X 

1 

X 

1 

X 

CAIS. 10  DEFINITIONS 

1 

X 

1 

X 

1 

X 

1 

X 

CAIS . SEQUENTIAL  10 

1 

X 

1 

X 

1 

1 

CAIS. DIRECT  10 

1 

X 

1 

1 

1 

CAIS .  TEXT  10 

1 

X 

1 

X 

1 

X 

1 

X 

CAIS. SCROLL  TERMINAL 

1 

1 

1 

X 

1 

CAIS. PAGE  TERMINAL 

1 

1 

1 

X 

1 

CAIS. FORM  TERMINAL 

1 

j 

1 

X 

1 

CAIS . MAGNETICTAPE 

1 

1 

1 

-  + 

1 

X 

A  secondary  storage  file  In  the  CA1S  represents  a  disk  or  other  random  access  storage  file.  Secondary 
storage  files  may  be  created  by  use  of  the  CREATE  procedures  specified  in  the  packages 
CAIS.SEQUENTIAL_IO,  CAIS.D!RECT_IO.  and  CAIS.TEXT_  IO. 

A  queue  file  In  the  CAIS  represents  a  sequence  of  information  that  Is  accessed  In  a  flrst-in,  flrst-out 
manner.  There  are  three  kinds  of  CAJS  queue  flies:  solo,  copy  and  mimic.  A  solo  queue  operates  like  a 
simple  queue,  Initially  empty,  in  which  all  writes  append  information  to  the  end  and  all  reads  are 
destructive.  A  copy  queue  operates  like  a  solo  queue  except  that  It  has  initial  contents  which  are 
copied  from  another  file;  after  the  creation  of  the  copy  queue.  It  is  Independent  or  the  file.  A  mimic 
queue  operates  like  a  solo  queue  except  that  it  has  initial  contents  that  are  the  same  as  the  contents 
of  another  file;  after  the  creation  of  the  mimic  queue,  the  mimic  queue  and  the  file  are  mutually 
dependent.  This  means  that.  If  Information  Is  written  to  the  mimic  queue  file.  It  Is  appended  to  the 
other  file  as  well  at  an  implementation  defined  time  which  is  no  later  than  CLOSE  of  the  mimic  queue 
file;  the  effect  on  the  mimic  queue  file  of  writing  or  appending  to  the  other  file  is  Implementation 
defined.  Solo  queue  files  may  be  created  by  use  of  the  CREATE  procedures  in  uhe  packages 
CAJS.SEQUENTlAJL_IO  and  CA1S.TEXT_10.  Copy  and  mimic  queue  flies  may  be  created  by  use 
of  the  COUPLE  procedure  in  the  package  IO_CONTROL. 

A  terminal  file  In  the  CATS  represents  an  Interactive  terminal  device.  Three  kinds  of  terminal  devices 
are  distinguished  in  the  CAJS:  scroll,  page  and  form.  These  are  distinguished  because  they  have 
different  characteristics  which  require  specialized  interfaces.  Scroll  and  page  terminals  may  be 
represented  either  by  a  single  terminal  file  for  Input  and  output  or  by  two  terminal  files,  one  for  Input 
and  one  for  output.  The  implementation  determines.  Tor  each  physical  terminal,  whether  it  will  be 
represented  by  one  or  two  terminal  flics.  If  two  terminal  files  are  used  to  represent  the  terminal  input 
and  output,  then  the  Implementation  maintains  an  Implicit  association  between  the  two  files.  A  form 
terminal  Is  represented  by  a  single  terminal  file  for  both  Input  and  output. 

A  magnetic  tape  drive  file  in  the  CAIS  represents  a  magnetic  tape  drive.  Operations  on  magnetic 
tape  drive  files  can  affect  cither  the  magnetic  tape  or  the  drive.  Interfaces  must  be  provided  outside 
the  CAIS  for  the  creation  of  terminal  flics  and  magnetic  tape  drive  files. 

Several  predefined  attributes  are  applicable  to  file  nodes.  The  attributes  ACCESS _ METHOD, 
l'ILE_KIND,  QUEUE_KIND.  and  TERMINAL_  KIND  provide  information  about  the  contents  of  a 
file  node  and  how  it  may  be  accessed. 
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It  is  possible  that  a  single  file  node  may  have  more  than  one  access  method,  as  specified  by  the 
predefined  attribute  ACCESS  _METHOD.  The  value  of  the  attribute  ACCESS  _  METHOD 
determines  the  packages  that  may  operate  upon  the  file.  The  predefined  values  for  the  attribute 
ACCESS  _ METHOD  are  SEQUENTIAL,  DIRECT,  and  TEXT  or  any  list  combination  of  these.  A 
value  of  SEQUENTIAL  indicates  that  the  CAJS. SEQUENTIAL  _  (O  package  may  be  used.  A  value  of 
DIRECT  indicates  that  the  package  CAJS.DIRECT_IO  may  be  used.  A  value  of  TEXT  Indicates 
that  the  package  CAIS.TEXT_IO  may  be  used. 

The  attribute  FILE  _  KIND  denotes  the  kind  of  file  that  is  represented  by  the  contents  of  the  file 
node.  The  predefined  values  for  the  attribute  FILE_KIND  are  S£CONDARY_STORAGE. 
QUEUE.  TERMINAL,  and  MAGNETIC_TAPE.  These  values  determine  which  packages  may  be 
used  to  operate  on  files,  as  shovn  in  TABLE  VIII. 

File  nodes  with  a  FILE_K!ND  value  of  QUEUE  also  have  a  predefined  attribute  QUEUE_KIND. 
The  predefined  values  for  the  attribute  QUEUE_KIND  are  SOLO.  MIMIC,  and  COPY. 

File  nodes  with  a  FILE_KIND  value  of  TERMINAL  also  have  a  predefined  attribute 
TERMINAL _ KIND.  The  values  SCROLL,  PAGE,  and  FORM  are  predefined  for  this  attribute.  In 
addition,  terminal  file  nodes  will  have  a  value  of  TEXT  for  the  attribute  ACCESS_METHOD. 

When  a  QUEUE  file  node  is  created  with  QUEUE_K1ND  of  COPY  or  MIMIC,  a  relationship  of  the 
predefined  relation  COUPLE  is  established  from  the  QUEUE  node  to  the  file  node  which  provides  the 
queue  s  initial  contents. 

The  above  discussion  is  summarized  in  TABLE  IX. 


IO-.» 
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Table  EX. 


File  node  predefined  attributes,  attribute  values  and 
relation 


Secondary 
Storage  Quaua 


Magnetic 

Teralnal  Tape 


ACCESS_METHOD 

SEQUENTIAL 

DIRECT 

TEXT 

FILEJtIND 

SECONDARY  STORAGE 
QUEUE 
TERMINAL 
MAGNETIC  TAPE 
Qu.'UE_KIND 
SOLO 
MIMIC 
COPY 

TERM I NAL_K I ND 
SCROLL” 

PAGE 

FORM 

COUPLE 


A 

V 

V 

V 
A 

V 


A 

V 


V 

A 


V 

A 


A 

V 

V 

V 


V 

A 


A  =  an  attribute  or  relation  which  appliee  to  the  file  node 
V  =  an  attribute  value  which  the  attribute  can  have  for  the  file  node. 


I 

I 


The  input  and  output  operations  in  the  packages  in  in  s  section  are  expressed  as  operations  on  objects 
of  some  file  type,  rather  than  directly  In  terms  of  th<  external  files.  These  objects  are  files  which  are 
internal  to  a  CAIS  process  (internal  files).  Internal  liles  are  Identified  by  file  handles.  Throughout 
this  document,  the  word  file  is  used  to  mean  an  Ada  external  file,  while  in  the  [LRM|  the  word  file  is 
used  to  mean  an  Internal  file.  The  mode  of  a  file  determines  the  Intents  with  which  its  associated  file 
node  can  be  opened.  These  corresponding  modes  and  intents  are  given  In  TABLE  X. 


Table  X.  Mo<  ■>  and  intents 

If  th«  MODE  la: 

the  INTENT  aur  establish  the  right  to: 

IN  FILE 

read  contents 

OUT  FILE 

vrlts  contents 

INFILE 

read  and  write  contents 

APPEND_FILE 

! _ 

appand  conter  ts 
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5.3.1.  Package  IO_DEFINITIONS 

This  package  defines  the  types  and  exceptions  associated  with  file  nodes. 

type  character juiray  is  array  (CHARACTER)  of  BOOLEAN; 

type  FILE_NODE  is  (INFILE,  INOUT_FILE,  OUT_FILE.  APPEND_FILE) ; 

type  file_type  is  limited  private; 

type  FUNCTICN_KEY_DESCRIPTOR (LENGTH:  POSITIVE)  is  private; 

type  TABENUMERATION  is  (HORIZONTAL ,  VERTICAL)  ; 

type  POSITION  TYPE  is 
record 

ROW  :  NATURAL; 

COLUVN  :  NATURAL; 

end  record; 


CHARACTER _ ARRAY  provides  information  concerning  the  characters  that  can  be  obtained  during 
a  GET  operation.  FILE_MODE  Indicates  the  type  of  operations  that  are  to  be  permitted  on  a  file. 
Analogous  to  the  [CRM]  type  FILE_TYPE  and  the  CAIS  type  NODE_TYPE,  the  CA1S  provides  a 
type  FILE_TYPE  whose  values  are  references  to  Internal  files.  FILE_TYPE  Is  used  for  controlling 
the  operations  on  all  files.  FUNCTlON_KEY_ DESCRIPTOR  is  used  to  determine  the  function 
keys  entered  from  a  terminal.  TAB _ ENUMERATION  is  used  to  specify  the  kind  of  tab  stop  to  be 
set.  POSITION_TYPE  is  used  to  specify  a  position  on  a  terminal. 

This  package  also  provides  the  definitions  for  all  exceptions  generated  by  the  Input  and  output 
packages.  These  definitions  are  comparable  to  those  specified  in  the  package  IO_ EXCEPTIONS  in 
the  [LRM]. 


5.3.2.  Package  DIRECT— IQ 

This  package  provides  facilities  for  direct-access  input  and  output  to  CAIS  files  comparable  to  those 
described  in  the  DIRECT_IO  package  of  [LRM].  Files  written  with  the  CAIS.DIRECT_IO  are  also 
readable  by  C^VIS. SEQUENTIAL _  IO,  if  the  two  packages  are  instantiated  with  the  same  generic 
ilata  type. 

The  package  specification  and  semantics  of  the  CAJS.DIRECT_  IO  are  comparable  to  those  of  the 
[LRM]  package  DIRECT_IO.  All  subprograms  present  In  the  [LRM]  package  DIRECT_IO  are 
present  in  this  CAIS  package.  The  following  sections  demonstrate  only  the  specifics' ions  and 
semantics  that  differ. 

5.3.2. 1.  Subtypea  and  constants 

subtype  filejtype  is  cais. redefinitions. file_type; 

r.ubtype  file_mode  is  cais. redefinitions. file_node; 

IN_FILE  :  constant  FILEJTODE  :=  CAIS. IO_DEFINITIONS. IN_FILE; 

INOUT_FILE  :  constant  FILe'mODE  :=  CAIS.  IO_DEFINITIONS .  INOUT_FILE; 

OUT_FIL£  :  constant  FILEJIODE  :=  CAIS.  REDEFINITIONS. OUT_FILE; 

FILE_TYPE  describes  the  type  for  file  handles  for  all  direct  input  and  output  operations. 
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FILE_MODE  indicates  whether  input  operations,  output  operations  or  boih  can  be  performed  on  the 
direct-access  file. 


5. 3. 2. 2.  Creating  a  direct  input  or  output  file 


procedure  create  (file: 


in  out  FILE  TYPE; 


BASE: 

in 

NODE  TYPE: 

KEY: 

in 

RELATIONSHIP  KEY  := 

LATEST_KEY 

RELATION: 

in 

RELATION 

NAME  := 

DEFAULT  RELATION; 

NODE: 

in 

FILE_MODE 

=  INOUT_FILE ; 

FORM: 

in 

LIST_TYPE 

=  EMPTY~LIST; 

ATTRIBUTES: 

in 

LIST_TYPE 

=  EMPTY_LIST , 

ACCESS_CONTROL : 

in 

LIST_TYPE 

=  EMPTY^LIST; 

LEVEL: 

in 

LIST  TYPE 

=  EMPTY- LIST) 

Purpose: 

This  procedure  creates  a  file  and  its  file  node:  each  element  of  the  file  is  directly  addressable  by 
an  index.  The  [LRM]  defines  what  constitutes  jin  element.  The  attribute  ACCESS_METIIOD 
is  assigned  the  value  "(DIRECT,  SEQUENTIAL)"  as  part  of  the  creation. 


The  FORM  parameter  is  used  to  provide  file  characteristics  concerning  the  creation  of  the  file. 
The  predefined  file  characteristic  ESTIMATED _ SIZE  may  be  used  to  specify  an  approximation 
to  the  number  of  storage  units  (l.e,  bytes  or  blocks)  that  should  be  writable  to  the  file.  The 
ESTIMATED _ SIZE  characteristic  is  specified  as  "(ESTIMATED _ SIZE  =  >  n)",  where  "n"  Is 
any  NATURAL  number. 

The  ATTRIBUTES  parameter  defines  and  provides  Initial  values  for  attributes  of  the  node.  The 
ACCESS_CONTROL  parameter  specifies  initial  access  control  information  to  be  established  for 
the  created  node  (see  Section  4.4.2. 1  for  details). 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  file  node  is  to  be  created. 

The  value  of  the  attribute  FILE  KIND  for  the  file  node  will  be  SECONDARY  STORAGE. 


Parameters: 


FILE 

BASE 

KEY 

RELATION 

MODE 

FORM 


is  a  file  handle,  initially  closed,  to  be  opened. 

is  an  open  node  handle  to  the  node  which  will  be  the  source  of  the  primary 
relationship  to  the  new  node 

is  the  relationship  key  of  the  primary  relationship  to  be  created, 
is  the  relation  name  of  the  primary  relationship  to  be  created, 
indicates  the  mode  of  the  file, 

Indicates  file  characteristics. 


ATTRIBUTES  defines  Initial  values  for  attributes  of  the  newly  created  node. 


Iil'i 
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ACCESS  _  CONTROL 

defines  the  initial  access  control  information  associated  with  the  created  node. 


LEVEL  defines  the  classification  label  for  the  created  node. 


Exceptions: 

NAME_  ERROR 

is  raised  if  a  node  already  exists  for  the  node  specified  by  KEY  and  RELATION,  if 
KEY  or  RELATION  is  syntactically  Illegal,  or  if  any  node  Identifying  a  group 
specified  In  the  given  ACCESS  _  CONTROL  parameter  Is  unobtainable  or 
inaccessible. 

USE_ ERROR  Is  raised  If  any  of  the  parameters  ACCESS _ CONTROL,  LEVEL  or  ATTRIBUTES 
Is  syntactically  or  semantically  illegal.  USE_ ERROR  is  also  raised  If  interpretation 
of  the  ATTRIBUTES  parameter  would  result  In  modification  or  creation  of  any 
predefined  attribute.  USE_ERROR  Is  also  raised  if  RELATION  is  the  name  of  a 
predefined  relation  that  cannot  be  modified  or  created  by  the  user. 

STATUS _ ERROR 

Is  raised  If  BASE  is  not  an  open  node  handle  or  If  FILE  Is  an  open  file  handle  prior 
to  the  call. 


INTENT  _  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  append 
relationships. 

SECURITY_  VIOLATION 

is  raised  if  the  operation  represents  a  violation  or  miui<  iiory  access  controls. 
SECURITY _ VIOLATION  Is  raised  only  if  the  conditions  I  >r  other  exceptions  are 
not  present. 

Additional  Interface: 

procedure  create  (file:  in  out  file  type; 


NAME: 

in 

NAMESTRING 

MODE: 

in 

FILE~M0DE  : 

=  INOUT_FILE; 

FORM: 

in 

listjtype 

:=  EMPTY_LIST; 

ATTRIBUTES: 

in 

LIST_TYPE 

:=  EMPTY_LIST; 

ACCESS_C0NTR0L : 

in 

LIST_TYPE 

:=  EMPTY_LIST ; 

LEVEL: 

in 

LISr~TYPE 

:=  EMPTY  LIST! 

is 

BASE  :  NODE_TYPE; 
begin 

OPEN (BASE ,  BASE_PATH (NAME) .  (1=>APPEND_RELATI0NSHIPS) ) ; 
CREATE (FILE,  BASE,  LAST JCEY (NAME) ,  LAST  RELATION (NAME) . 

MODE,  FORM,  ATTRIBUTES,  ACCESS_CONTROL .  LEVEL): 
CLOSE (BASE) ; 
exception 

when  others  => 

CLOSE  (FILE) ; 

CLOSE (BASE) ; 
raise : 

end  CREATE; 
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5. 3. 2.3.  Opening  a  direct  input  or  output  file 


procedure  open  (file: 

NODE : 
MODE: 


in  out  FILE_TYPE ; 
in  NODE_TYPE ; 
in  FILE  MODE) 


Purpose: 

This  procedure  opens  a  file  handle  on  a  Hie.  given  an  open  node  handle  to  the  file  node:  each 
element  of  the  file  is  directly  addresi-able  by  an  Index. 

Parameters: 

KILE  Is  a  file  handle,  initially  closed,  to  be  opened. 

NODE  is  an  open  node  handle  to  the  file  node. 

MODE  Indicates  the  mode  of  the  file. 

Exceptions: 

USE_ERROR  Is  raised  if  the  attribute  ACCESS_METHOD  of  the  file  node  does  not  have  the 
value  DIRECT,  If  the  element  type  of  the  file  does  not  correspond  with  the  element 
type  of  this  Instantiation  of  the  CAIS.DIRECT_ IO  package,  or  if  the  mode  is 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  FILE  is  an  open  file  handle  at  the  time  of  the  call  on  OPEN  or  if  NODE 
is  not  an  open  node  handle. 

INTENT  _  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  access  rights 
required  for  the  MODE,  as  specified  In  TABLE  X. 


Additional  Interface: 

procedure  open (FILE:  in  out  file  type; 

NAME:  in  NAME  STRING; 

MODE:  in  FILEMODE  ) 

is 

NODE  :  NODETYPE; 

begin 

case  mode  is 

when  INJFTLE  =>  OPEN  (NODE,  NAME.  (1  =  >READ_  CONTENTS)  )  ; 
when  OUT_FILE  =>  OPEN(NODE,  NAME,  (1=>WRITE_C0NTENTS))  ; 
when  IN0UT_FILE  =>OPEN( node,  name, 

(READ_CONTENTS . WRITE _CONTE NTS) )  ; 
when  APPENC_FILE  ->raise  USE_ERR0R; 
end  case; 

OPEN (FILE,  NODE,  MODE) 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (FILE) ; 

CLOSE (NODE) ; 
raise; 
end  OPEN; 
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Notes: 

The  effects  on  the  open  file  handle  of  closing  an  open  node  handle  on  its  node  are 
Implementation-defined.  In  particular,  no  assumption  can  be  made  about  the  access  protection 
provided  by  the  node  model. 

5.3.2.4.  Deleting  a  direct  input  or  output  file 

procedure  DELETE  (FILE:  in  out  FILE_TYPE)  ; 


Purpose: 

In  addition  to  the  semantics  specified  in  [LRM|,  if  the  node  associated  with  the  open  file  handle 
FILE  is  not  already  unobtainable,  this  node  is  made  unobtainable  as  if  a  call  to  the 
DELETE_NODE  procedure  had  been  made.  If  this  node  is  already  unobtainable  by  this  call, 
no  exception  other  than  STATUS_  ERROR  may  be  raised  by  this  procedure. 

Parameters: 

FILE  is  an  open  file  handle  on  the  file  being  deleted. 


Exceptions: 

NAME_  ERROR 

Is  raised  If  the  parent  node  of  the  node  associated  with  the  file  identified  by  FILE  is 
inaccessible. 

USE__  ERROR  Is  raised  If  any  primary  relationships  emanate  from  the  node  associated  with  the  file 
Identified  by  FILE. 

STATUS _ ERROR 

Is  raised  if  FILE  is  not  an  open  file  handle. 

LOCK  _  ERROR 

Is  raised  if  access  with  intent  WRITE_ RELATIONSHIPS  to  the  parent  of  the  node 
to  be  deleted  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

ACCESS  _  VIOLATION 

Is  raised  If  the  current  process  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  the  parent  of  the  node  to  be  deleted  with  intent 
WRITE  _  RELATIONSHIPS  or  to  obtain  access  to  the  node  to  be  deleted  with 
intent  EXCLUSIVE  _  WRITE.  ACCESS  _V!OI*ATION  Is  only  raised  If  the 
conditions  for  NAME _  ERROR  are  no'  present. 

SECl  TRITY_  VIOLATION 

is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY _  VIOLATION  is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 


I  OR 
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5.3.3.  Package  SEQUENTIAL_IO 

This  package  provides  facilities  for  sequentially  accessing  data  elements  in  CAIS  files.  [LRM]  defines 
what  constitutes  an  element.  These  facilities  are  comparable  to  those  described  in  the 
SEQUENTIAL _10  package  of  [LRM]. 

The  package  spociflcation  and  semantics  of  the  CAIs.SEQl  i^NTIAL_IO  are  comparable  to  those  or 
the  [LRM]  package  SEQUENTIAL_  IO.  All  subprograms  present  in  the  [LRM)  package 
SEQUENTIAL_IO  are  present  In  this  CAIS  package.  The  following  sections  demonstrate  only  the 
specifications  and  semantics  that  differ. 


5.3.3.I.  Subtypea  and  constants 

subtype  filejtype  is  cais  ^definitions  .  file_type ; 

subtype  file  mode  is  cais. io_definitions.fi».e_mode; 

IN_FILE  :  constant  FILEMODE  :=  CAIS.IODEFINITIONS.INFILE; 
imout  file  :  constant  file'mode  :=  cais.io'definitions.i NOUTF ILE . 

OUT_FILE  :  constant  FILE”mODE  :  =  CAIS. IO~DEFIMITIOHS.QUT_FILE; 

APPENDFILE  :  constant  FILi_MODE  :=  CAIS. IODEFINITIONS.APPENDFILE; 

FILE_TYPE  describes  the  type  for  file  handles  for  all  sequential  Input  and  output  operations. 
FILE_MODE  Indicates  whether  input  operations,  output  operations  or  both  can  be  performed  on  the 
sequential-access  file.  A  mode  of  APPEND_FILE  causes  any  elements  that  are  written  to  the 
specified  file  to  be  appended  to  the  elements  that  are  already  In  the  file. 


5. 3. 3. 2.  Creating  a  sequential  input  or  output  file 
procedure  create  (file:  in  out  file  type; 


RASE: 

in 

NODE  TYPE; 

KEY: 

in 

RELATIONSHIP JCEY  :=  LATEST 

RELATION : 

in 

RELATI  0N_NAME  .  = 

DEFAULT  RELATION; 

MODE: 

in 

FILE_M0DE 

=  IN0UT_FILE; 

FORM: 

in 

LISTJTYPE 

=  EMPTYLIST; 

ATTRIBUTES: 

in 

LISTJTYPE 

=  EMPTYLIST; 

ACCESS_C0NTR0L : 

in 

LISTJTYPE 

=  EMPTYJ.IST; 

LEVEL:- 

in 

LIST_TYPE 

=  EMPTY  LIST) ; 

Purpose; 

This  procedure  creates  a  file  and  Its  file  node;  each  element  of  the  file  is  sequentially  accessible. 
The  attribute  ACCESS _  METHOD  is  assigned  the  value  "(SEQUENTIAL)"  as  part  of  the 
creation. 

The  FORM  parameter  is  used  to  provide  file  characteristics  concerning  the  creation  of  the  file. 
The  predefined  file  characteristic  ESTIMATED _ SIZE  may  be  used  to  specify  an  approximation 
to  the  number  of  storage  units  (e  g.,  bytes  or  blocks)  that  should  be  writable  to  the  Hie.  The 
ESTIMATED _ SIZE  characteristic  is  specified  as  "(ESTIMATED _ SIZE  =  >  n)".  where  "n"  is 
any  NATURAL  number. 

The  ATTRIBUTES  parameter  defines  and  provides  Initial  values  for  attributes  of  the  node.  The 
ACCESS_CONTROL  parameter  specifies  Initial  access  control  information  to  be  established  for 
the  created  node  (see  Section  4.4.2. 1  for  details). 
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The  LEVEL  parameter  specifies  the  security  level  at  which  the  file  node  is  to  be  created. 

The  default  value  for  the  attribute  F1LE_KIND  for  the  file  node  Is 
SECONDARY_STORAGE.  The  default  value  may  be  overridden  by  explicitly  specifying  a 
value  of  QUEUE  In  the  attributes  parameter  (i.e.,  "(FILE_KIND  =>  QUEUE)"),  in  which 
case  the  value  of  the  attribute  QUEUE_KIND  Is  SOLO. 


Parameters: 

FILE 

BASE 

KEY 

RELATION 

MODE 

FORM 


Is  a  file  handle,  Initially  closed,  to  be  opened. 

is  an  open  node  handle  to  the  node  which  will  be  the  source  of  the  primary 
relationship  to  the  new  node. 

Is  the  relationship  key  of  the  primary  relationship  to  be  created, 
is  the  relation  name  of  the  primary  relationship  to  be  created. 

Indicates  the  mode  of  the  file, 
indicates  file  characteristics. 


ATTRIBUTES  defines  Initial  values  for  attributes  of  the  newly  created  node. 


ACCESS  _  CONTROL 

defines  the  initial  access  control  information  associated  with  the  created  node. 


LEVEL  defines  the  classification  label  for  the  created  node. 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  a  node  already  exists  for  the  node  specified  by  KEY  and  RELATION  or 
If  KEY  or  RELATION  Is  syntactically  Illegal  or  If  any  node  Identifying  a  group 
specified  In  the  given  ACCESS  _  CONTROL  parameter  Is  unobtainable  or 
inaccessible. 

USE_ERROR  Is  raised  if  any  of  the  parameters  ACCESS_CONTROL,  LEVEL  or  ATTRIBUTES 
is  syntactically  or  semantically  Illegal.  USE_  ERROR  Is  also  raised  if  interpretation 
of  the  ATTRIBUTES  parameter  would  result  In  creation  of  any  predefined 
attribute  other  than  FILE_KIND.  USE_ERROR  Is  also  raised  if  RELATION  is 
the  name  of  a  predefined  relation  that  cannot  be  created  by  the  user. 

STATUS _ ERROR 

Is  raised  If  BASE  is  not  an  open  node  handle  or  If  FILE  is  an  open  file  handle  prior 
to  the  call. 

INTENT  _  VIOLATION 

Is  raised  If  BASE  was  not  opt-ued  with  an  intent  establishing  the  right  to  append 
relationships. 
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SECURITY  _  VIOI .  ATIO  N 

is  aised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SEC  URITY _ VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

Additional  Interface: 


procedure  create  (file: 

in  out  FILE  TYPE; 

NAME: 

in 

NAME  STRING; 

MODE: 

in 

FILE_MODE 

= 

INOUT_FILE; 

FORM: 

in 

LIST~TYPE 

= 

EMPTYJ.IST; 

ATTRIBUTES: 

in 

LIST~TYPE 

= 

EMPTY~LIST; 

ACCESS_C0NTR0L 

in 

LIST~TYPE 

= 

EMPTY  LIST; 

LEVEL:” 

is 

in 

LIST_TYPE 

= 

**) 

BASE  :  NODE_TYPE; 
begin 

OPEN (BASE ,  BASE  PATH (MAKE) ,  (1=>APPEND_RELATI0NSHIPS)) ; 
CREATE (FILE,  BASE.  LAST  KEY ( NAME ) .  LAST  RELATION (NAME) . 

MODE.  FORM.  ATTRIBUTES,  ACCESS_CONTROL ,  LEVEL); 
CLOSE (BASE) : 
exception 

when  others  => 

CLOSE (FILE) ; 

CLOSE  (BASE)  ; 
raise: 

end  CREATE; 


S.3.3.3.  Opening  a  sequential  input  or  output  file 


procedure  open  (file: 

NODE: 

MODE: 


in  out  FILE_TYPE; 
in  NODE  TYPE; 

in  FILE~MODE) ; 


Purpose: 

This  procedure  opens  a  file  handle  on  a  file,  given  an  open  node  handle  on  the  file  node;  each 

element  of  the  file  Is  sequentially  accessible. 

Parameters: 

FILE  Is  a  file  handle,  Initially  closed,  to  be  opened. 

NODE  Is  an  open  node  handle  to  the  file  node. 

MODE  Indicates  the  mode  of  the  file. 

Exceptions: 

USE_ERROR  Is  raised  if  the  attribute  ACCESS_ METHOD  of  the  file  node  does  not  have  the 
value  SEQUENTIAL  or  it  the  clement  type  of  the  (lie  does  not  correspond  with  the 
element  type  of  this  Instantiation  of  the  CAIS.S’EQUKNTIAL_IO  package. 
USE _  ERROR  is  also  raised  If  the  node  Identified  by  NODE  has  a  value  of  QUEUE 
for  the  attribute  FILE_KIND  and  a  value  of  MIMIC  for  the  attribute 
QUEUE_KIND  and  the  mimic  m  ''tie  file  identified  by  FILE  is  being  opened  with 
MODE  other  than  IN_FILE  but  the  coupled  file  (see  Section  5.3.5.13)  has  been 
deleted. 
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STATUS _ ERROR 

Is  raised  if  FILE  is  an  open  file  handle  at  the  time  of  the  call  on  OPEN  or  If  NODE 
Is  not  an  open  node  handle. 


INTENT_  VIOLATION 

Is  raised  if  NODE  was  not  opened  with  an  Intent  establishing  the  access  r  ghts 
required  for  the  MODE,  as  specified  in  TABLE  X. 


Additional  Interface: 

procedure  open  (file:  in  out  file  type: 

NAME:  in  NAME  "string; 

MODE:  in  FILE~MODE  } 

is 

NODE  :  NODE  TYPE; 
begin 

case  mode  is 

when  IN  FILE  =>  OPEN(NODE,  NAME.  (i=>READ_CONTENTS))  ; 
when  OUT  FILE  =>  0PEN(N0DE.  NAME.  (1=>WRITE_C0NTENTS))  ; 
when  INCUT_FILE=>OPEN  (NODE .  NAME . 

(READ  JIONTENTS , NRITECONTENTS) ) ; 
when  APPENDFILE  =>  OPEN  (NODE.  NAME  ,~(1=>APPEND_C0NTENTS)  )  ; 
end  case; 

OPEN (FILE.  NODE.  MODE); 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (FILE) ; 

CLOSE (NODE); 
raise; 
end  OPEN; 


S.3.3.4.  Deleting  a  sequential  input  or  output  file 
procedure  delete  (file:  in  out  file_type)  ; 


Purpose: 

In  addition  to  the  semantics  specified  In  (LRM),  If  the  node  associated  with  the  open  file  handle 
FILE  Is  not  already  unobtainable,  this  node  is  made  unobtainable  as  if  a  call  to  the 
DELETE_NODE  procedure  had  been  made.  If  this  node  Is  already  unobtainable  by  this  call,  no 
exception  other  than  STATUS _  ERROR  may  be  raised  by  this  procedure. 

Parameters; 

FILE  is  an  open  file  handle  on  the  file  being  deleted. 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  parent  node  of  the  node  associated  with  the  Hie  Identified  by  FILE  is 
Inaccessible. 

USE_ ERROR  Is  raised  if  any  primary  relationships  emanate  from  the  node  associated  with  the  file 
Identified  by  FILE. 

STATUS  _  ERROR 

is  raised  If  FILE  is  not  open  file  handle. 
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LOCK_KUROR 

is  raised  if  access  with  intent  WRITE_RELATlONSHlPS  to  the  parent  of  the  nixie 
to  be  deleted  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

ACCRSS_  VIOLATION 

is  raised  if  the  current  process  does  not  have  sufficient  discretionary  access  control 
rights  to  obtain  access  to  the  parent  of  the  node  to  be  deleted  with  intent 
WRITE_RELATIONSIIIPS  or  to  obtain  access  to  the  node  to  be  deleted  with 
intent  EXCLUSIVE_  WRITE.  ACCESS  _  VIOLATION  is  only  raised  ir  the 
conditions  for  NAMK_ ERROR  are  not  present. 

SECURITY  _  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY_  VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


5.3.4.  Package  TEXT_IO 

This  package  provides  facilities  for  the  input  and  output  of  textual  data  to  CAIS  files.  [LRVI]  defines 
what  constitutes  an  element  of  data.  These  facilities  are  comparable  to  those  specified  in  the  package 
TEXT _ IO  In  [LRM].  All  subprograms  present  in  the  (LRM)  package  TEXT_IO  are  present  in  this 
CAIS  package.  The  following  sections  demonstrate  only  the  specifications  and  semantics  that  differ. 


5.3.4.I.  Subtypes  and  constants 

subtype  file  type  is  cais  .  I0_DEFINITI0NS .  FILE_TYPE; 

subtype  FILE  MODE  is  CAIS .  IQ_DEFIMITIONS .  FILE_MODE: 

IK  FILE  :  constant  FILE_MODE  :=  CAIS.  I0J5EFINITIDNS.  INFILE; 

INOUTFILE  :  constant  FILEMODE  :=  CAIS .  ^DEFINITIONS .  INOUT  FILE; 

OUTFILE  :  constant  FILEMODE  :=  CAIS. IO~DEFIMITIONS.OUT_FILE; 

appendfile  :  constant  file  mode  :  =  cais.  io'definitions. app£nd_file. 

F!LE_TYPE  describes  the  type  for  file  handles  Tor  all  text  input  and  output  operations 
FILE_MODE  indicates  whether  input  operations,  output  operations  or  both  can  be  performed  on  the 
text  file.  A  mode  of  APPEND_FILE  causes  any  text  written  to  the  specified  file  to  be  appended  in 
the  text  that  Is  already  in  the  file. 


5.3. 4. 2.  Creating  a  text  input  or  output  file 

procedure  create  (file.  in  out  file_type; 


BASE: 

in 

NODE  TYPE; 

KEY: 

in 

RELATIONSHIP JCEY  :=  LATEST 

RELATION: 

in 

RELATION  NAME  :  = 

DEFAUVT-REI-ATION; 

MODE: 

in 

FILE_M0DE 

=  INOUT_FILE ; 

FORM: 

in 

LIST_TYPE 

=  EMPTY~LIST; 

ATTRIBUTES: 

in 

LIST_TYPE 

=  EMPTY-LIST; 

ACCESS_C0NTR0L : 

in 

LIST~TYPE 

=  EMPTY-LIST; 

LEVEL:" 

in 

LIST  TYPE 

=  EMPTY "LIST) ; 

Purpose: 

This  procedure  creates  a  file  and  Its  file  node;  the  file  is  textual.  The  attribute 
AC  (  ESS_ METHOD  is  assigned  the  value  "(TEXT)"  as  part  of  the  creation. 
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The  FORM  parameter  is  used  to  provide  Hie  characteristics  concerning  the  creation  of  the 
external  file.  The  predefined  file  characteristic  ESTIMATED _ SIZE  may  be  used  to  specify  an 
approximation  to  the  number  of  storage  units  (e.g.,  bytes  or  blocks)  that  should  be  writable  to 
the  file.  The  ESTIMATED _ SIZE  characteristic  is  specified  as  "(ESTIMATED _ SIZE  =>  n)". 
where  "n"  Is  any  NATURAL  number. 

The  ATTRIBUTES  parameter  defines  and  provides  Initial  values  for  attributes  of  the  node.  The 
ACCESS  _CONTROL  parameter  specifies  Initial  access  control  information  to  be  established  for 
the  created  node  (see  Section  4.4.2. 1  for  details). 

The  LEVEL  parameter  specifies  the  security  level  at  which  the  file  node  Is  to  be  created. 

The  default  value  for  the  attribute  FILE_KINI>  Is  SECONDARY _ STORAGE.  The  default 
value  may  bo  overridden  by  explicitly  specifying  a  value  of  QUEUE  in  the  ATTRIBUTES 
parameter  i.e.,  "(FILE_KIND  =>  QUEUE)").  If  the  value  of  FILE  _  KIND  is  QUEUE,  the 
default  value  of  the  attribute  QUEUE _ KIND  is  SOLO. 


Parameters: 

FILE 

BASE 

KEY 

RELATION 

MODE 

FORM 


Is  a  file  handle.  Initially  closed,  to  be  opened. 

Is  an  open  node  handle  to  the  node  which  will  be  the  source  of  the  primary 
relationship  to  the  new  node. 

Is  the  relationship  key  of  the  primary  relationship  to  be  created, 
is  the  relation  name  of  the  primary  relationship  to  be  created. 

Indicates  the  mode  of  the  file. 

Indicates  file  characteristics. 


ATTRIBUTES  defines  Initial  values  for  attributes  of  the  newly  created  node. 

ACCESS  _  CONTROL 

defines  the  initial  access  control  information  associated  with  the  created  node. 


LEVEL  defines  the  classification  label  for  the  created  node. 


Exceptions: 

NAME  _  ERROR 

is  raised  If  a  node  already  exists  for  the  node  specified  by  KEY  and  RELATION  or 
If  KEY  or  RELATION  Is  syntactically  Illegal  or  If  any  node  Identifying  a  group 
specified  In  the  given  ACCESS_CONTROL  parameter  Is  unobtainable. 

USE _ ERROR  is  raised  if  any  or  the  parameters  ACCESS _ CONTROL,  LEVEL  or  ATTRIBUTES 
is  syntactically  or  semantically  Illegal.  USE_ ERROR  is  also  raised  If  interpretation 
of  the  ATTRIBUTES  parameter  would  result  In  modification  or  creation  of  a 
predefined  attribute  other  than  FILE_KIND.  USE_ ERROR  Is  also  raised  If 
RELATION  Is  the  name  of  a  predefined  relation  which  cannot  be  created  by  the 
user. 
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STATUS _ ERROR 

Is  raised  if  BASE  is  not  an  open  node  handle  or  if  FILE  is  an  open  file  handle  prior 
to  the  call. 


INTENT  _  VIOLATION 

is  raised  if  BASE  was  not  opened  with  an  intent  establishing  the  right  to  append 
relationships. 

SECURITY  _  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls 
SECURITY_ VIOLATION  Is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 


procedure  create  (FILE: 

NAME: 

MODE: 

in  out  FILE  TYPE; 
in  NAME_STRINC; 

in  FILEMODE  = 

INOUTJFILE; 

FORM: 

in 

LISTTYPE  := 

EMPTY~LIST; 

ATTRIBUTES: 

in 

LIST  TYPE  := 

EMPTYLIST; 

ACCESSCONTROL: 

in 

LIST_TYPE  := 

EMPTYLIST; 

LEVEL: 

in 

LISTTYPE  := 

EMPTY~LIST) 

M 


BASE  :  NODE  TYPE; 
begin 

OPEN (BASE ,  BASEPATH (NAME) ,  (1=> APPEND  RELATIONSHIPS)); 
CREATE (FILE.  BASE,  LAST  KEY (NAME) .  LAST  RELATION (NAME) . 

MODE.  FORM.  ATTRIBUTES.  ACCESS  CONTROL,  LEVEL); 
CLOSE (BASE); 
exception 

when  others  => 

CLOSE (FILE); 

CLOSE (BASE) ; 
raise: 

end  create: 


S.3.4.3.  Opening  a  text  input  or  output  file 


procedure  OPEN  (FILE: 

NODE 

MODE 


in  out  FILE  TYPE; 
in  NODE  "TYPE; 

in  FILE~M0DE) ; 


Purpose: 

This  procedure  opens  a  file  handle  on  a  file  that  has  textual  contents,  given  an  open  node  handle 
on  the  file  node. 


Parameters: 

PILE  is  a  file  handle,  Initially  closed,  to  be  opened. 

NODE  is  an  open  node  handle  to  the  file  node. 

MODE  Indicates  the  mode  of  the  file. 

Exceptions: 


1 15 
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USE_ERROR  is  raised  If  the  attribute  ACCESS_METHOD  of  the  file  no<  o  does  not  have  the 
value  TEXT  or  the  element  type  of  the  file  does  not  corresp.  d  with  the  element 
type  of  this  instantiation  of  the  CAIS.TEXT_IO  package.  LSE_ERROR  Is  also 
raised  if  the  node  identified  by  NODE  has  a  value  of  QUEUE  for  the  attribute 
FILE_KlND  and  a  value  of  MIMIC  for  the  attribute  QUEUE_KIND  and  the 
mimic  queue  file  identified  by  FILE  is  being  opened  with  MODE  other  than 
IN  _  FILE  but  the  coupled  file  (see  Section  5.3.5.13)  has  been  deleted. 
USE_  ERROR  is  also  raised  if  the  node  identified  by  NODE  has  a  value  of 
TERMINAL  or  MAG NETIC_ TAPE  for  the  attribute  FILE_KIND  and  the  MODE 
is  APPEND  _  FILE. 

STATUS _ ERROR 

Is  raised  If  FILE  Is  an  open  file  handle  at  the  time  of  the  call  on  OPEN  or  if  NODE 
Is  not  an  open  node  handle. 

INTENT_  VIOLATION 

is  raised  if  NODE  has  not  been  opened  with  an  intent  establishing  the  access  rights 
required  for  the  MODE,  as  specified  in  TABLE  X. 


Additional  Interface: 

procedure  open  (file:  in  out  file  TYPE; 

NAME:  in  NAVE  JSTRINC, 

MODE:  in  FILE~MOOE) 

is 

NODE  :  NODE_TYPE; 
begin 

CMC  MODE  is 

when  IN  FILE  =>  OPEN  (NODE ,  NAME.  U=>READ_CONTENTS)  )  ; 
when  OUTFILE  =>  OPEN  (NODE.  NAME,  (1=>WRITE_C0NTENTS))  ; 
when  INOUT  FILE  =>OPEN  (NODE ,  NAME , 

(READ_CONTENTS, WRITE  CONTENTS)) ; 
when  APPENDFILE  =>  OPEN  (NODE,  NAME .  (1=>APPEND_C0NTENTS)  )  ; 
end  case; 

OPEN (FILE,  NODE,  MODE); 

CLOSE (NODE) ; 
exception 

when  others  => 

CLOSE (FILE) ; 

CLOSE (NODE) : 
raise; 
end  open; 

Notes: 

If  the  file  identified  by  FILE  is  a  mimic  queue  file  which  is  being  opened  to  cad  and  Its  coupled 
file  (see  Section  5.3.5.13)  has  been  deleted  or  has  fewer  elements  than  ex  >octed  to  be  in  the 
mimic  queue  file  (e.g.,  if  some  of  the  contents  of  the  coupled  file  have  been  deleted),  read 
operations  on  the  mimic  queue  file  will  encounter  an  end  of  file. 


S.3.4.4.  Deleting  a  text  input  or  output  file 
procedure  delete(file:  in  out  file_type>; 


Purpose: 

In  addition  to  the  semantics  specified  In  [LRM],  the  node  associated  with  he  open  file  handle 
FILE  Is  made  unobtainable  as  If  a  call  to  the  DELETE_NODE  procedure  h:nl  been  made. 
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Parameters: 

FILE  Is  an  open  file  handle  on  the  file  being  deleted. 


Exceptions: 


NAMK_  ERROR 

is  raised  if  the  parent  node  of  the  node  associated  with  the  file  identified  bv  HI  I',  is 
inaeressible. 

USK_ERROR  is  raised  if  any  primary  relationships  emanate  from  the  node  associated  with  th.  file 
identified  by  Fll.lv 

STATUS _ ERROR 

is  raised  if  FILE  is  not  an  open  file  handle. 

LOCK  _  ERROR 

is  raised  if  access  with  intent  WRITE_ RELATIONSHIPS  to  the  parent  of  the  node 
to  be  deleted  cannot  be  obtained  due  to  an  existing  lock  on  the  node. 

AO( 'KSS  _  VIOLATION 

is  raised  if  the  current  process  docs  not  have  sufficient  discretionary  access  cot  trol 
rights  to  obtain  access  to  the  parent  of  the  node  to  be  deleted  with  in  ^nt 
VVRITE_RELATIONSHIPS  or  to  obtain  access  to  the  node  to  be  deleted  with 
intent  EXCLUSIVE  _  WRITE.  ACCESS  _VIOLATION  is  only  raised  if  the 
conditions  for  NAME_ ERROR  are  not  present. 

SECURITY  _  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  contiols. 
SECURITY_ VIOLATION  is  raised  only  if  the  conditions  for  other  exceptions  are 
not  present. 

5.3.4. 5.  Resetting  a  text  file 

procedure  reset  (FILE:  inout  filejtype; 

MODE:  in  FILE_M0DE) ; 

Purpose: 

In  addition  to  the  semantics  specified  In  [LRM],  application  of  this  procedure  to  a  flic  whi<  h 
represents  a  magnetic  tape  drive  will  cause  the  magnetic  tape  to  be  rewound  to  the  flic  m,v  k 
immediately  preceding  the  current  tape  position.  See  Section  5.3.9  for  more  Information  on 
magnetic  tapes. 

Parameters: 

FILE  Is  an  open  file  handle  on  the  file  begin  reset. 

MODE.  indicates  the  mode  of  the  file. 


Exceptions: 

USF._ ERROR  Is  raised  if  the  node  associated  with  the  file  Identified  by  FILE  has  a  valie  of 
TERMINAL  or  MAG NETIC_ TAPE  for  the  attribute  FILE_KINI>  and  the  M>  l>E 
is  APPEND  FILE. 
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5. 3. 4.6.  Reading  from  a  text  file 
procedure  G£T(. . ; 


Purpose: 

These  procedures  read  characters  from  the  specified  text  file. 

For  all  values  of  the  attribute  FILE_KINT>  the  CAiS  defines  only  reading  of  the  printable 
ASCII  characters  plus  the  format  effectors  called  horizontal  tabulation,  vertical  tabulation, 
carriage  return,  line  feed,  and  form  feed.  All  of  the  printable  characters  plus  the  horizontal 
tabulation  and  vertical  tabulation  characters  may  be  read  as  characters.  The  characters  carriage 
return  and  line  feed  are  to  be  treated  as  line  terminators  whether  encountered  singly  or  together 
(i.e.,  CR.  LF.  CRLF,  and  LFCR  are  line  terminators).  The  character  form  feed  is  to  be  treated 
as  the  page  terminator. 

When  text  Is  being  read  from  a  file  whose  file  node  attribute  FILE_KIND  has  the  value 
TERMINAL.  It  Is  expected  that  most  Implementations  will  provide  facilities  for  editing  the  Input 
entered  by  the  user  before  making  the  characters  available  to  a  program  for  reading. 


5.3.4. 7.  Writing  to  a  text  file 
procedure  put(.  . ; 


Purpose: 

These  procedures  write  characters  to  the  specified  file. 


The  CAIS  supports  the  transfer  of  Information  to  and  rrom  a  single  magnetic  tape  volume.  Data 
transferred  to  and  from  magnetic  tapes  may  consist  of  the  following  characters: 


Charactsrs 


Representation  of  Characters 


all  printable  characters 

horizontal  tab 

vertical  tab 

carriage  return 

line  teralnator 

page  teralnator 

file  teralnator 

fill  character 


corresponding  ASCII  characters 

ASCII. HT 

ASCII. VT 

ASCII. CR 

ASCII. LF 

ASCII . FF 

zero  or  sore  fill  characters  tollovcd 


laaediately  by  a  tape  aark. 
ASCII. NUL 


Use  of  other  characters  is  not  defined. 

S.3.4.8.  Setting  the  input  file 

procedure  set_input(file  :  in  filetype); 


Purpose: 

In  addition  to  the  semantics  specified  in  the  [l,RM|,  the  file  node  associated  with  the  file 
identified  by  FILE  becomes  the  target  of  the  relationship  of  the  predefined  relation 
CURRENT_INPUT  of  the  current  process  node. 

Parameters: 
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FILE  is  an  open  file  handle. 


Exceptions: 

MODE  _  ERROR 

Is  raised  If  the  mode  of  the  I'i  identified  by  FILE  is  Ol'T_FILE  or 
APPEND  _  FILE. 

ST  ATUS_  ERROR 

Is  raised  If  FILE  Is  not  an  open  file  handle. 

LOCK  _  ERROR 

is  raised  if  the  current  process  node  is  LOCKed  against  writing  relationships. 

5. 3. 4.9.  Setting  the  output  file 

procedure  set_output (file  :  in  f1le_type)  ; 

Purpose: 

In  addition  to  the  semantics  specified  In  the  [LRM],  the  file  node  associated  with  FILE  becomes 
the  target  of  the  relationship  of  the  predefined  relation  CURRENT_OUTPUT  of  the  current 
process  node. 

Parameters: 

FILE  is  an  open  file  handle. 

Exceptions: 

MODE_ ERROR 

is  raised  if  the  mode  of  the  file  Identified  by  FILE  is  IN_FILE. 

STATUS _ ERROR 

is  raised  if  FILE  Is  not  an  open  file  handle. 

LOCK  _  ERROR 

is  raised  if  the  current  process  node  is  LOCKed  against  writing  relationships. 

5.3.4.10.  Setting  the  error  file 

procedure  set_error(fiue  :  in  filejtype)  , 

Purpose: 

Th'»  file  node  associated  with  the  file  Identified  by  FILE  becomes  the  target  of  the  relationship  of 
the  predefined  relation  CURRENT_ERROR  or  ihe  current  process  node, 

Parameters: 

FILE  Is  an  open  fill'  handle. 

Exceptions: 

Page  3-193 


1 1« 


PROPOSED  MIL-STD-C  AIS 
31  JANUARY  198.S 

MODE_ ERROR 

is  raised  If  the  mode  of  the  file  Identified  by  FILE  Is  IN  _  FILE. 

STATUS _ ERROR 

is  raised  if  FILE  is  not  an  open  file  handle. 

LOCK _ ERROR 

Is  raised  if  the  current  process  node  is  LOCKed  against  writing  relationships. 

5.3.4.11.  Determining  the  standard  error  file 
function  standard  error  return  file  type; 


Purpose: 

This  function  returns  an  open  file  handle  to  the  target  node  of  the  relationship  of  the  predefined 
relation  STANDARD_ ERROR  that  was  set  at  the  start  of  program  execution. 

Parameters: 

None. 

Exceptions: 

LOCK  _  ERROR 

Is  raised  If  the  current  process  node  Is  locked  against  reading  relationships. 

5.3.4.12.  Determining  the  current  error  file 

function  current  error  return  FILE  type; 


Purpose: 

This  function  returns  an  open  file  handle  to  the  target  node  of  the  relationship  of  the  predefined 
relation  CURRENT_ERROR  which  is  either  the  standard  error  file  or  the  file  specified  in  the 
most  recent  invocation  of  SET_ERROR  In  the  current  process. 

Parameters: 

None. 

Exceptions: 

LOCK _ ERROR 

Is  raised  if  the  current  process  node  is  locked  against  reading  relationships. 


5.3.5.  Package  IQ _ CONTROL 

This  package  defines  facilities  that  may  be  used  to  modify  or  query  the  functionality  of  CAIS  flies.  It 
provides  for  association  of  Input  and  output  text  flies  with  an  output  logging  file.  It  also  provides 
facilities  for  forcing  data  from  an  Internal  file  to  Its  associated  external  file,  for  manipulation  of 
function  keys  and  prompt  strings  and  for  creating  mimic  and  copy  queues. 
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5.3.5. 1.  Obtaining  an  open  node  handle  from  a  file  handle 

procedure  OPENFILE  NODE  (FILE:  in  FILE_TYPE; 

NODE:  in  out  NODE  TYPE; 

INTENT:  in  INTENTION; 

TINE_LIWIT:  in  DURATION : =N0  DELAY) ; 


Purpose: 

This  procedure  returns  an  open  node  handle  for  the  node  associated  with  the  file  Identified  by 
FILE. 

Parameters; 

FILE  is  an  open  file  handle. 

NODE  Is  a  node  handle.  Initially  closed,  to  be  opened. 

INTENT  Is  the  intent  of  subsequent  operations  on  the  node;  the  actual  parameter  takes  the 

form  of  an  array  aggregate. 

TIME_LIMIT  specifies  a  time  limit  for  the  deiay  on  waiting  for  the  unlocking  of  a  node  in 
accordance  with  the  desired  INTENT. 

Exceptions: 

NAME_  ERROR 

Is  raised  If  the  node  to  which  a  handle  is  to  be  opened  is  inaccessible  or  if  It  is 
unobtainable  and  the  given  INTENT  Includes  any  intent  other  than  EXISTENCE. 

USE _  ERROR  is  raised  if  the  specified  INTENT  Is  an  empty  array. 

STATUS _ ERROR 

is  raised  if  FILE  Is  not  an  open  file  handle  or  If  NODE  Is  an  open  node  handle. 
LOCK  _  ERROR 

is  raised  if  the  OPEN_FILE_NODE  operation  is  delayed  beyond  the  specified 
time  limit  due  to  the  existence  of  locks  in  conflict  with  the  specified  intent. 

ACCESS  _  VIOLATION 

is  raised  IT  the  current  process'  discretionary  access  control  rights  are  Insufficient  to 
obtain  access  to  the  node  consistent  with  the  specified  INTENT. 
ACCESS _ VIOLATION  is  raised  only  if  the  conditions  for  NAME_ERROR  are 
not  present. 

SECURITY_  VIOLATION 

is  raised  if  the  operation  represents  a  violation  of  mandatory  access  controls. 
Sr,’,CURITY_ VIOLATION  Is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 
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5.3.5. 2.  Synchronizing  program  files  with  system  files 

procedure  synchronize  (file  in  file  type)  ; 

Purpose: 

This  procedure  forces  ail  data  that  has  been  written  to  the  internal  file  Identified  by  FILE  to  be 
transmitted  to  the  external  file  with  which  It  is  associated. 

Parameters: 

FILE  is  an  open  file  handle  on  the  internal  file  to  be  synchronized. 


Exceptions: 

USE_  ERROR  Is  raised  If  the  file  Identified  by  FILE  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  FILE  Is  not  an  open  file  handle. 

5.3.5.3.  Establishing  a  log  file 

procedure  set_log(file  in  file_type; 

LOG  FILE  :  in  file” TYPE) ; 

Purpose: 

This  procedure  associates  a  log  file  identified  by  LOG_FILE  With  the  nie  identified  by  FILE. 
All  elements  written  to  the  internal  file  Identified  by  FILE  are  also  written  to  Che  file  Identified 
by  LOG  _  FILE. 

Parameters: 

FILE  Is  an  open  file  handle  on  the  file  which  Is  to  have  a  log  file. 

LOG  FILE  is  an  open  file  handle  on  the  file  to  which  the  log  should  be  written. 


Exceptions: 

MODE_ ERROR 

Is  raised  if  the  mode  of  either  of  the  files  Identified  by  FILE  or  LOG  _  FILE  is 
IN  _  FILE. 

USE _  ERROR  Is  raised  if  the  nodes  associated  with  the  files  identified  by  FILE  and  LOG  _  FILE 
do  not  have  the  same  values  for  the  attribute  ACCESS_ METHOD  or  if  the  files  do 
not  have  compatible  elements  (implementation-defined). 

STATUS _ ERROR 

is  raised  if  FILE  and  LOG  _  FILE  are  not  both  open  file  handles. 
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5. 3. 5. 4.  Removing  a  log  file 

procedure  clear_log (file  :in  filejtype)  ; 


Purpose: 

This  procedure  removes  the  association  established  between  the  rile  ii'entiTied  by  FILE  and  Its 
log  file. 

Parameters: 

FILE  is  an  open  file  handle  on  a  file  that  has  a  log  file. 

Exceptions: 

STATUS _ ERROR 

Is  raised  If  FILE  Is  not  an  open  file  handle. 


Notes: 

If  FILE  Is  an  open  file  handle  and  there  Is  no  log  file,  this  procedure  has  no  effect. 

5.3.S.5.  Determining  whether  logging  ia  specified 

function  logging  (file  :in  FILE  TYPE) 
return  boolean; 

Purpose: 

This  function  returns  TRUE  If  the  file  Identified  by  FILE  has  a  log  rile  associated  with  It; 
otherwise,  it  returns  FALSE. 

Parameters: 

FILE  Is  an  open  file  handle. 

Exceptions: 

STATUS _ ERROR 

Is  raised  If  FILE  Is  not  an  open  file  handle. 

S.3.5.0.  Determining  the  log  file 

function  get  log  (file  :in  filejtype) 
return  file  type; 


Purpose: 

This  function  returns  an  open  file  handle  on  the  log  file  currently  associated  with  the  file 
Identified  by  FILE. 

Parameters: 

FILE  Is  an  open  file  handle. 

Exceptions: 
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USE_  ERROR  Is  raised  If  the  (lie  Identified  by  FILE  has  no  log  file. 
STATUS _ ERROR 

is  raised  if  FILE  is  not  an  open  file  handle. 


5. 3. 5.7.  Determining  the  file  size 


function  nuvber  of  elements  (file  :in  file  type) 
return  natural; 

Purpose: 

This  function  returns  the  number  of  data  elements  contained  in  the  file  Identified  by  FILE.  The 
package  that  was  used  to  write  the  elements  determines  what  constitutes  a  data  element. 


Parameters; 

FILE  is  an  open  file  handle  on  a  secondary  storage  or  queue  file. 


Exceptions: 

USE_ERROR  is  raised  if  the  value  of  the  attribute  FILE_KIND  of  the  node  associated  with  the 
file  Identified  by  FILE  is  TERMINAL  or  MAG  NF)TIC_  TAPE. 

STATUS_ ERROR 

Is  raised  if  FILE  is  not  an  open  file  handle. 


5.3.S.8.  Setting 


jrompt  string 


procedure  setprompt  (terminal  in  FILETYPE; 

PROMPT  :  in  STRING); 

Purpose: 

This  procedure  sets  the  prompt  string  for  the  output  terminal  file  associated  with  the  input 
terminal  file  Identified  by  TERMINAL.  All  future  requests  for  a  line  or  Input  from  the  Input 
terminal  file  identified  by  TERMINAL  will  first  output  the  prompt  string  to  the  associated 
output  terminal  file. 


Parameters: 

TERMINAL  Is  an  open  file  handle  Identifying  an  Input  terminal  file. 


PROMPT  Is  the  new  value  of  the  prompt  string. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  if  the  attribute  FILE_KINI>  or  if 
SCROLL  or  PAGE  Is  not  a  value  of  the  ntlri  uitc  TKRMINAL_K!ND  of  the  node 
associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

Is  raised  If  the  flic  Identified  by  TERMINAL  Is  not  of  mode  IN _ FILE  or 
INOUT_FILE. 

STATIJS_  ERROR 

Is  raised  If  TERMINAL  Is  not  an  open  flic  handle. 
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5. 3.5.0.  Determining  the  prompt  string 

function  getprompt  (terminal  :in  file  ttpe) 
return  string; 

Purpose: 

This  function  returns  the  current  prompt  string  for  the  input  terminal  Hie  identified  by 
TERMINAL. 

Parameters: 

TERMINAL  is  an  open  file  handle  Identifying  an  Input  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  attribute  FILE_KIND  or  if 
SCROLL  or  PAGE  Is  not  a  value  of  the  attribute  TERMINAL_KIND  of  the  node 
associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  identified  by  TERMINAL  is  not  of  mode  IN _  FILE  or 
lNOUT_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

5.3.5.10.  Determining  intercepted  characters 

function  I NTERCEPTED  CHARACTERS  (TERMINAL  :  in  FILE  TYPE) 
return  character  array: 


Purpose: 

This  function  returns  the  array  CHARACTER  _  ARRAY  that  Indicates  the  characters  that  can 
never  appear  in  the  input  terminal  file  identified  by  TERMINAL  due  to  characteristics  of  the 
underlying  system  and  the  individual  physical  terminal.  A  value  of  TRUE  indicates  that  the 
character  can  appear;  a  value  of  FALSE  Indicates  that  it  cannot  appear. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  input  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  attribute  FILE_KIND  of  the  node 
associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  is  not  of  mode  IN _ FILE  or 
INOUT_FILE. 

STATUS _ ERROR 

Is  raised  If  TERMINAL  Is  not  an  open  file  handle. 


Page  3-199 


PROPOSED  MIL-STD-CAIS 
31  JANTARY  l#8-S 

5.3.5.11.  Enabling  and  disabling  function  key  usage 

procedure  enable_functi on_keys  (terminal  : in  file_type; 

ENABLE  in  BOOLEAN); 


Purpose: 

This  procedure  establishes  whether  data  read  as  the  result  of  pressing  a  function  key  on  the 
physical  input  terminal  is  to  appear  in  the  input  terminal  file  as  ASCII  character  sequences  or  :>s 
function  key  Identification  numbers.  A  value  of  TRUE  for  ENABLE  indicates  that  the  funcii<n 
keys  should  appear  as  numbered  values.  A  value  of  FALSE  Indicates  that  the  function  kevs 
should  appear  as  ASCII  character  sequences.  The  function  keys  are  said  to  have  been  enabled  if 
the  value  of  ENABLE  is  TRUE. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  Input  terminal  file. 

ENABLE  indicates  how  function  keys  are  to  appear. 

Exceptions: 

USE_ ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  attribute  FILE_KIND  of  the  node 
associated  with  the  flic  identified  by  the  parameter  TERMINAL.  USE_ERROR  is 
also  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  OUT_FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  Is  not  an  open  file  handle. 


Notes: 

This  procedure  has  no  effect  on  read  operations  of  the  CAis.TEXT_IO  package. 

5.3.5.12.  Determining  function  key  usage 

function  function _keys_emabled  (terminal  :  in  filejtype) 
return  boolean; 


Purpose: 

This  function  returns  TRUE  if  the  function  keys  are  enabled,  l.e.,  they  appear  In  the  input 
terminal  file  as  numbered  values;  otherwise  It  returns  FALSE. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  input  terminal  file. 


Exceptions: 

USE_ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  attribute  FILE_KIND  of  the  node 
associated  with  the  file  identified  by  the  parameter  TERMINAL.  USE _  ERROR  Is 
also  raised  If  the  file  identified  by  TERMINAL  Is  of  mode  OUT _  FILE  or 
APPEND  FILE. 
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CLOSE (BASE) ; 
exception 

when  others  => 
CLOSE (BASE) ; 

raise; 

end  COUPLE; 


procedure  couple  (queue_base: 

QUEUE"  KEY: 

QUEUE  JtELATION : 

FILENAME: 

form" 

ATTRIBUTES: 
ACCESS _C0NTR0L: 
LEVEL:" 

is 


in  N0DE_TYPE ; 
in  RELATIONSHIPKEY  := 
LATEST_KEY ; 
in  RELATION  NAME  :  = 

DEFAULT_R£LATION; 

in  name_strinoT 

in  LISTJTYPE  :=  EMPTr_LIST; 

in  list’type; 

in  LISTJTYPE  :=  EMPTY_LIST; 
in  LIST  TYPE  :=  EMPTy"lIST) 


FILENODE  :  NODE  TYPE; 
begin 

OPEN (FILE_NODE .  FILENAME 

(READ~ATTRIBUTES ,  READ_CONTENTS) ) ; 

COUPLE (QUEUE  BASE.  QUEUE  KEY,  QUEUE  RELATION. 

FILE  NODE.  FORM,  ATTRIBUTES.  ACCESS  CONTROL.  LEVEL); 
CLOSE (FILENODE) ; 

exception 

when  others  => 

CLOSE (FILENODE) ; 

raise; 

end  COUPLE; 


procedure  couple  (queue  name  : 

FILENAME: 

FORM? 

ATTRIBUTES: 
ACCESSCONTROL : 
LEVEL: 

is 


in  NAMESTRINC. 
in  NAME~  STRING ; 
in  list "type  := 

in  LISTJTYPE ; 
in  LIST~TYPE  := 

in  list"type  := 


EMPTY  LIST; 


EMPTYLIST; 
EMPTY  LIST) 


FILENODE  :  NODE  TYPE; 

QUEUE  BASE  :  NODE  TYPE; 
begin 

OPEN (QUEUEBASE .  BASE  PATH (QUEUE_NAME) . 

(1=> APPEND  RELATIONSHIPS)); 

OPEN (FILE  NODE.  FILE  NAME. 

(READ'ATTRIBUTES ,  READ_CONTENTS) ) ; 

COUPLE (QUEUEBASE,  LASTKEY(QUEUENAME) . 

LAST_RELATION(QUEUE_NAVE) , 

FILE  NODE,  FORM,  ATTRIBUTES,  ACCESS_CONTROL,  LEVEL); 
CLOSE (QUEUE  BASE); 

CLOSE (FILE_NODE) ; 
exception 

when  others  => 

CLOSE (QUEUE  BASE) ; 

CLOSE (FILE_N0DE) ; 
raise; 

end  COUPLE; 


Notes: 

l?e:id  operations  on  a  mimic  queue  Hie  whose  coupled  file  has  lieen  deleted  or  has  fewer  elements 
than  expected  in  the  mimic  queue  file  (e.g.,  if  some  of  the  contents  of  the  coupled  file  have  been 
deleted)  will  encounter  an  end  of  file.  Attempts  to  opena  mimic  queue  file  whose  coupled  file 
has  been  deleted  with  MODI')  other  than  IN_FI1,K  raises  a  USh)_ KRROIt  exception.  Attempts 
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to  open  with  MODE  other  than  IN-FILE  a  mimic  queue  file  whose  coupled  file  has  been  deleted 
will  raise  a  USE _  ERROR  exception. 


5.3.6.  Package  SCROLL— TERMINAL 

This  package  provides  the  functionality  of  a  scroll  terminal.  A  scroll  terminal  consists  of  two  devices: 
an  Input  device  (keyboard)  and  an  associated  output  device  (a  printer  or  display).  A  scroll  terminal 
may  be  accessed  either  as  a  single  file  of  mode  INOUT_FILE  or  as  two  files:  one  of  mode  IN  FILE 
(the  keyboard)  and  the  other  of  mode  OUT_FILE  (the  printer  or  display).  As  keys  are  pressed  on  the 
scroll  terminal  keyboard,  the  transmitted  characters  are  made  available  for  reading  by  the 
CAIS.SCROLL_ TERMINAL  package.  As  characters  are  written  to  the  scroll  terminal  file,  they  are 
displayed  on  the  output  device. 

The  output  devices  for  scroll  terminals  have  positions  In  which  printable  ASCII  characters  may  be 
graphically  displayed.  The  positions  are  arranged  Into  horizontal  rows  and  vertical  columns.  Each 
position  is  identifiable  by  the  combination  of  a  positive  row  number  and  a  positive  column  number. 
An  output  device  for  a  scroll  terminal  has  a  fixed  number  of  columns  and  might  have  a  fixed  number 
of  rows.  The  rows  a.e  Incrementally  Indexed  starting  with  one  after  performing  the  NEW _  PAGE 
(see  Section  5.3.6.19)  operation.  The  columns  are  incrementally  indexed  starting  with  one  at  the  left 
side  of  the  output  device. 

The  active  position  on  the  output  device  of  a  scroll  terminal  Is  the  position  at  which  the  next 
operation  wilt  be  performed.  The  active  position  Is  said  to  advance  If  (1)  the  row  number  of  the  new 
position  is  greater  than  the  row  number  of  the  old  position  or  (2)  the  row  number  of  the  new  position 
Is  the  same  as  the  row  number  of  the  old  position  and  the  new  position  has  a  greater  column  number. 
Similarly,  a  position  is  said  to  precede  the  active  position  if  (l)  the  row  number  of  the  position  is  less 
than  the  row  number  of  the  active  position  or  (2)  the  row  number  of  the  position  Is  the  same  as  the 
row  number  or  the  active  position  and  the  column  number  of  the  position  Is  smaller  than  the  column 
number  of  the  active  position. 

5.3.6.1.  Subtypea 

subtype  FILE  TYPE  is  CAIS .  IO_DEFIXITIOXS .  FILE_TYPE; 
subtype  function  key  descriptor  Is 

CAIS . 10  JJEFfNITIONS . FUNCTION _KEY_DESCRIPTOR ; 

subtype  position_type  is  cais.io_definitions.position_type: 

subtype  TAB_ENUKERATION  is  CAIS.I0_DEFINITI0HS.TAB_ENUKERATT3N; 

FILE_TYPE  describes  the  type  ror  file  handles.  FUNCTION_KBY_ DESCRIPTOR  Is  used  to 
obtain  information  about  function  keys  read  from  a  terminal.  POSITION-TYPE  describes  the  type  of 
a  position  on  a  terminal.  TAB _ ENUMERATION  Is  used  to  specify  the  kind  of  tab  stop  to  be  set. 

5.3.6.2.  Setting  the  active  position 

procedure  set_position (terminal:  in  file  type; 

POSITION:  in  POSITION  TYPE); 


Purpose: 

This  procedure  advances  the  active  position  to  the  specified  POSITION  in  the  output  terminal 
file  identified  by  TERMINAL. 
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Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

I’OSITION  is  the  new  active  position  in  the  output  terminal  file. 

Exceptions: 

USE_ ERROR  Is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND,  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  Is  of  mode  IN _  FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

LAYOUT  _  ERROR 

is  raised  if  the  position  does  not  exist  on  the  terminal  or  the  position  precedes  the 
active  position. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

Additional  Interface: 

procedure  set  position  (position:  in  position  type) 

is 

begin 

SET  POSITION(CURREJfT_OUTPUT,  POSITION)  ; 
end  SET  POSITION; 


5.3.O.3.  Determining  the  active  position 

function  get  position (terminal:  in  file_type) 
return  position_typE; 

Purpose: 

This  function  returns  the  active  position  of  the  output  terminal  file  identified  by  TERMINAL. 
Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

Exceptions: 

USK_ ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_K!ND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_ KIND  of  the  flic 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 
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MODE_ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  get_position 

return  positiontype 

ia 

begin 

return  GET_PosiTiOM(cusREJ(T_oinwr) ; 
end  get  position  ; 


S.3.0.4.  Determining  the  site  of  the  terminal 

function  term  inalsize  (terminal:  in  filetype) 
return  position_type; 

Purpose: 

This  function  returns  the  maximum  row  and  maximum  column  of  the  output  terminal  Die 
identified  by  TERMINAL.  A  value  of  zero  for  the  row  number  Indicates  that  the  row  number  Is 
unlimited. 


Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  or  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

Is  raised  ir  the  rile  Identified  by  TERMINAL  is  or  mode  IN_FILE. 

STATUS _ ERROR 

Is  raised  If  TERMINAL  is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 


function  terminalsize 

return  position  type 


is 

begin 
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return  terminal_size(current_qutput)  ; 
end  TERMINAL  SIZE; 


5. 3.0.5.  Setting  a  tab  stop 

procedure  set  tab (terminal ;  in  file  type; 

KIND:  in  TAbJe NUMERATION  :=  HORIZONTAL); 

Purpose: 

This  procedure  establishes  a  horizontal  tab  stop  at  the  column  of  the  active  position  If  KIND  Is 
HORIZONTAL,  or  a  vertical  tab  stop  at  the  row  of  the  active  position  if  KIND  is  VERTICAL. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

KIND  is  the  kind  (horizontal  or  vertical)  of  tab  stop  to  be  set. 

Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  t he  value  of  the  predefined  attribute  FILK_KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  Hie  identified  by  the  parameter  TERMINAL. 
USE _ ERROR  is  also  raised  if  the  number  of  rows  for  the  terminal  is  unlimited  and 
KIND  is  VERTICAL. 

MODE_ ERROR 

is  raised  If  the  file  identified  by  TERMINAL  Is  of  mode  IN  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  set  tab  (kind:  in  tab_enumeration  :=  horizontal) 

is 

begin 

SET_TAB (CURRENT_OUTPUT ,  KIND); 

end  set  tab: 


5. 3. 0.0.  Clearing  a  tab  stop 

procedure  clear  tab (terminal:  in  file  type; 

KIND:  in  TAB_E NUMERATION  :=  HORIZONTAL); 

Purpose: 

This  procedure  removes  a  horizontal  tab  stop  from  the  column  of  the  active  position  if  KIND  is 
HORIZONTAL  or  a  vertical  tab  stop  from  the  row  of  the  active  position  If  KIND  Is 
VERTICAL. 
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Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

KIND  Is  the  kind  (horizontal  or  vertical)  of  tab  stop  to  be  removed. 


Exceptions: 

USE_ERROR  Is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILK_K1ND  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIM>  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  >r  if  there  Is 
no  tab  stop  of  the  designated  kind  at  the  active  position. 

MODE_ ERROR 

Is  raised  If  the  file  Identified  by  TERMINAL  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  h  cause  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  clear_tab(kind:  in  TABENUWERAtion  :  =  horizontal) 

ia 

begin 

CLEAR  TAB (CTJRREMT  OUTPUT,  KIND) ; 
end  CLEAR  TAB: 


5.3.O.7.  Advancing  to  the  next  tab  position 
procedure  tab  (terminal  in  filettpe; 

KINS:  in  TABENUMERATION  :=  HORIZONTAL: 

COUNT:  in  POSITIVE  :=  1); 

Purpose: 

This  procedure  advances  the  active  position  COUNT  tab  stops.  Horizontal  advancem  nt  causes 
a  change  In  only  the  column  number  of  the  active  position.  Vertical  advancemcm  causes  a 
change  In  only  the  row  number  of  ihe  active  position. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

KIND  Is  the  kind  (horizontal  or  vertical)  of  lab  to  be  advanced. 

COUNT  Is  a  positive  Integer  indicating  the  number  of  tab  stops  the  active  position  is  to 

advance. 

Exceptions: 
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USE_ ERROR  is  raised  if  TERMINAL  i9  not  the  value  of  the  predefined  attribute  FILE  KIND. 

SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL,  or  there  are 
fewer  than  COUNT  tab  stops  of  the  designated  kind  after  the  active  position. 

MODE  ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN _ FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  tab<kind:  in  tab_evuveration  :=  horizontal; 
COUNT:  in  POSITIVE  :=  1) 

is 

begin 

TAB (CURRENTOUTPUT .  KIND,  COUNT); 
end  TAB: 


5. 3. 0.8.  Sounding  a  terminal  bell 

procedure  bell  (terminal:  in  FILE  TYPE) ; 

Purpose: 

This  procedure  sounds  the  bell  (beeper)  on  the  terminal  represented  by  the  output  terminal  Tile 
identified  by  TERMINAL. 

Parameters: 

TERMINAL  Is  an  open  flic  handle  on  an  output  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  '.be  value  of  the  pr.  defined  attribute  FILE_KIND  or 
SCROLL  is  not  a  value  of  t.:e  oredefined  attribute  TERMINAL_  KIND  of  the  file 
node  associated  with  the  file  loenllfled  by  »he  parameter  TERMINAL. 

MODE  ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN _ FILE. 

ST  ATUS  _  ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 
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procedure  BELL 

ia 

begin 

BELL (CURRENT_OUTPUT) ; 
end  BELL; 


5. 3. 6.0.  Writing  to  the  terminal 

procedure  put  (terminal:  in  filettpe; 

ITEM:  in  CHARACTER) ; 

Purpose: 

This  procedure  writes  a  single  character  to  the  output  terminal  file  Identified  by  TERMINAL 
and  advances  the  active  position  by  one  column. 

Parameter: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

ITEM  Is  the  character  to  be  written. 


Exceptions: 

USE _  ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE _ KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  or  mode  IN _ FILE. 

STATUS _ ERROR 

Is  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interfaces: 

procedure  put  (item:  in  character) 

is 

begin 

PUT (CURREMT_OUTPUT .  ITEM); 
end  PUT; 

procedure  put  (terminal:  in  file_type; 

item:  in  strIng) 

is 

begin 

for  index  in  item' first  . .  item ’last  loop 
PUT (TERMINAL.  ITEM (INDEX) ) ; 
end  loop; 
end  PUT; 

procedure  put(item:  in  string) 

is 
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begin 

PUT (CURR£NT_QUTPUT ,  ITEM) ; 
end  PUT; 


Notes; 

After  a  character  Is  written  in  the  rightmost  position  of  a  row,  the  active  position  is  the  first 
position  of  the  next  row. 


5.3.0.10.  Enabling  echo  on  a  terminal 

procedure  set_echo  (terminal  :  in  filejtype; 

TO:  in  BOOLEAN  :=  TRUE) ; 


Purpose: 

This  procedure  establishes  whether  characters  which  appear  in  the  input  terminal  (lie  identified 
by  TERMINAL  are  echoed  to  its  associated  output  terminal  file.  When  TO  is  TRUE,  each 
character  is  echoed  to  the  output  terminal  file.  When  TO  Is  FALSE,  each  character  which 
appears  In  the  Input  terminal  file  is  not  echoed  to  its  associated  output  terminal  file. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  input  terminal  file. 

TO  indicates  whether  or  not  to  echo  input  characters. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  PILE_KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  is  or  mode  OUT_FILE  or 
APPEND  FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  set  echo  (TO:  in  boolean  =  true) 

is 

begin 

SETECHO (CURRENT  INPUT,  TO); 
end  SET  ECHO ; 
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5.3.0.11.  Querying  echo  on  a  terminal 

function  echo  (terminal  :  in  file  type) 
return  boolean; 


Purpose: 

This  function  returns  TRUE  if  echo  is  enabled;  otherwise  it  returns  FALSE. 
Parameters: 

TERMINAL  is  an  open  file  handle  on  an  input  terminal  file. 


Exceptions: 

USE_ ERROR  Is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  is  of  mode  OUT_FILE  or 
APPEND  _FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  echo  return  boolean 

is 

begin 

return  echoccurrent_input)  ; 
end  echo; 


5.3.0.12.  Determining  the  number  of  function  keys 

function  maximum_function_key(tehninal:  in  i  file_type) 
return  natural; 


Purpose: 

This  function  returns  the  maximum  function  key  identification  number  that  can  be  returned  by 
a  GET  operation  on  the  Input  terminal  file  identified  by  TERMINAL. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  Input  terminal  file. 

Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  atiribute  FILE  KIND  or 
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SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  OUT  FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  maximum  function  key  return  na  ral 

is 

begin 

return  maximum_functionjcey<current  nput); 

end  MAXIMUM  FUNCTION  KEY; 


5.3.6.13.  Reading  a,  character  from  a  terminal 

procedure  get  (terminal:  in  FIL£_TYPE; 

ITEM:  out  CHARACTER; 

KEYS:  OUt  FUNCTION  KEY  DESCRIPTOR)  ; 


Purpose: 

This  procedure  reads  either  a  single  character  Into  ITEM  or  a  single  function  key  identification 
number  Into  KEYS  from  the  input  terminal  file  Identified  by  TERMINAL. 

Parameters: 

TERMINAL  is  an  open  flic  handle  on  an  Input  terminal  file. 

ITEM  is  the  character  that  was  read. 

KEYS  Is  the  description  of  the  function  key  Identification  number  that  was  read. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 


MODE _ ERROR 

Is  raised  If  the  file  identified  by  TERMINAL  is  of  mode  OUT_FILE  or 
APPEND  _  FILE. 

STATUS_ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 
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DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

Additional  Interface: 

procedure  GET  (ITEM:  out  CHARACTER; 

KEYS:  OUt  FUNCTION  KEY  DESCRIPTOR) 

is 

begin 

GET (CURRENT_INPUT ,  ITEM.  KEYS); 
end  GET; 


Notes: 

This  procedure  will  only  return  function  key  Identification  numbers  in  KEYS  If  function  keys 
have  been  enabled  (see  Section  5.3.5.  II).  Otherwise  the  characters  in  the  ASCII  character 
sequence  representing  the  function  key  will  appear  one  at  a  time  in  ITEM. 

6.3.0.14.  Reading  all  available  characters  from  a  terminal 

procedure  get  (terminal:  in  file  type; 

ITEM:  out  STRING; 

LAST:  OUt  NATURAL; 

KEYS:  OUt  FUNCTION _KEY_DESCRIPTDR)  ; 

Purpose: 

This  procedure  successively  reads  characters  and  function  key  Identification  numbers  Into  ITEM 
and  KEYS  respectively,  until  either  all  positions  of  ITEM  or  KEYS  are  rilled  or  there  are  no 
more  characters  available  in  the  input  terminal  file.  Upon  completion,  LAST  contains  the  index 
of  the  last  position  In  ITEM  to  contain  a  character  that  has  been  read. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  Input  terminal  file. 

ITEM  is  the  string  of  characters  that  were  read. 

LAST  is  the  position  of  the  last  character  read  In  ITEM. 

KEYS  Is  a  description  of  the  function  key  Identification  numbers  that  were  read. 

Exceptions: 

USE_ ERROR  is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  identified  by  TERMINAL  is  of  mode  OUT_EII,E  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  is  not  an  open  file  handle. 
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DKVICE_  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  get  (item:  out  string; 

LAST:  out  NATURAL; 

KEYS:  out  FUNCTION_KEY_DESCRIPTOR) 

is 

begin 

GET (CURRENT_INPUT .  ITEM,  LAST,  KEYS) ; 
end  GET; 


Notes: 

This  procedure  will  only  return  function  key  identification  numbers  In  KEYS  ir  function  keys 
have  been  enabled  (see  Section  5.3.5.11).  Otherwise  the  characters  in  the  ASCII  character 
sequence  representing  the  function  key  will  appear  in  ITEM.  If  there  are  no  elements  available 
for  reading  Trom  the  input  terminal  file,  then  LAST  has  a  value  one  less  than  ITEMTIRST  and 
FUNCTION  _KEY_COUNT(KEYS)  (see  Section  5.3.6.15)  Is  equal  to  zero. 

5.3.0.15.  Determining  the  number  of  function  keys  that  were  read 

function  functi  on  key  count  (keys  :  in  fumction  key  descriptor) 
return  NATURAL; 


Purpose: 

This  function  returns  the  number  of  function  keys  described  In  KEYS. 
Parameters: 

KEYS  is  the  function  key  descriptor  being  queried. 


Exceptions: 

None 


5.3.0.10.  Determining  function  key  usage 

in  FUNCTION_KEY_DESCRIPTQR; 

in  positive"; 

out  POSITIVE; 
out  NATURAL)  ; 


procedure  functi on_key  (keys  : 

INDEX: 

KEY_IDENTIFIER : 
POSITION: 


Purpose: 

This  procedure  returns  the  identification  number  of  a  function  key  and  the  position  in  the  string 
(read  at  the  same  time  as  the  function  keys)  of  the  character  following  the  function  key. 

Parameters: 

KEYS  is  the  description  of  the  function  key  identification  numbers  that  were  read. 

INDEX  Is  the  Index  In  KEYS  of  the  function  key  to  be  queried. 
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KEY_  IDENTIFIER 

Is  the  Identification  number  of  a  function  key. 

POSITION  Is  the  position  of  the  character  read  after  the  function  key. 


Exceptions: 

CONSTRAINT_  ERROR 

Is  raised  if  INDEX  is  greater  than  FUNCTION _KEY_COUNT(KEYS). 


5.3.6.17.  Determining  the  name  of  a  function  key 

FILEJTTPE; 
POSITIVE; 
out  STRING; 
out  POSITIVE) ; 


procedure  function_key_name (terminal :  in 

KEY_IDENTIFIER :  in 
KEY~NAME: 

LAST: 


Purpose: 

This  function  returns  (in  KEY_NAME)  the  string  identification  of  the  fin  lion  key  sequence 
designated  by  KEY_IDENTIF1ER.  It  also  returns  the  index  of  the  bo  character  of  the 
function  key  name  in  LAST. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  Input  terminal  file. 

KEY_  IDENTIFIER 

is  the  identification  number  of  a  function  key. 

KEY_NAME  is  the  name  of  the  key  designated  by  KEY_IDENTIFIER. 

I.AST  is  the  position  in  KEY_NAME  of  the  last  character  of  the  function  key  name. 


Exceptions: 

USE_ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

Is  raised  if  the  rile  identified  by  TERMINAL  is  of  mode  OUT_FILE  or 
APPEND_FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

CONSTRAINT  _  ERROR 

is  raised  if  the  value  of  KEY_  IDENTIFIER  is  greater  than 
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MAXIMUM  _  FUNCTION  _KEY(TERMINAL)  or  the  string  identification  or  the 
function  key  sequence  is  longer  than  the  string  KEY_NAME. 


Additional  Interface: 

procedure  function_key_name 

(KEY_IDENTIFIER:  !n  ”  POSITIVE; 

KEYJtAME:  OUt  STRING; 

LAST:  OUt  POSITIVE) 

is 

begin 

FUNCTION  KEY  NAME (CURRENT_ INPUT. 

KEY_IDENTIFIER.  KEY_NAME,  LAST); 
end  FUNCTION  KEY  NAME; 


5.3.6.18.  Advancing  the  active  position  to  the  next  line 

procedure  new  line  (terminal:  in  filetype; 

COUNT:  in  POSITIVE  :=  1); 


Purpose: 

This  procedure  advances  the  active  position  In  the  output  terminal  file  to  column  one,  COUNT 
lines  after  the  active  position. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

COUNT  is  the  number  of  lines  to  advance. 


Exceptions: 

USE_ERROR  Is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  Is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE  _  ERROR 

Is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  newline  (count:  in  positive  :=  t) 

is 

begin 

new  line (current  output,  COUNT) ; 
end  NEW  LINE; 
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5.3.0.19.  Advancing  the  active  position  to  the  next  page 

procedure  newpage (terminal:  in  file  type); 


Purpose: 

This  procedure  advances  the  active  position  In  the  output  terminal  file  to  the  first  column  of  the 
first  line  of  a  new  page. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 


Exceptions: 

USE_ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
SCROLL  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  IN _  FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  mew  page 

is 

begin 

MEWPAGE (CURREMTOUTPUT) ; 

end  new  page: 


5.3.7.  Package  PAGE _ TERMINAL 

This  package  provides  the  functionality  of  a  page  terminal.  A  page  terminal  consists  of  two  devices: 
an  input  device  (keyboard)  and  an  associated  output  device  (display).  A  page  terminal  may  be 
accessed  either  as  a  single  file  of  mode  INOUT_FILE  or  as  two  files:  one  of  mode  IN _  FILE  (the 
keyboard)  and  the  other  of  mode  OUT_FILE  (the  display).  As  keys  are  pressed  on  the  page  terminal 
keyboard,  the  transmitted  characters  are  made  available  for  reading  by  the 
CAJS.PAGE_TERM!NAL  package.  As  characters  are  written  to  the  page  terminal  file,  they  are 
displayed  on  the  output  device. 

The  display  for  a  page  terminal  has  positions  In  which  printable  ASCII  characters  may  l>o  graphically 
displayed.  The  positions  are  arranged  into  horizontal  rows  and  vertical  columns.  Each  position  is 
Identifiable  by  the  combination  of  a  row  number  and  a  column  number.  A  display  has  a  fixed  number 
of  rows  and  columns.  The  rows  and  columns  of  a  display  are  Identified  by  positive  numbers.  The 
rows  are  Incrementally  Indexed  starting  with  one  at  the  top  of  the  display.  The  columns  are 
Incrementally  Indexed  starting  with  one  at  the  left  side  of  the  display. 
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The  active  position  on  the  display  of  a  page  terminal  Is  the  position  at  which  the  next  operation  will 
be  performed.  The  active  position  is  said  to  advance  if  (1)  the  row  number  of  the  new  position  is 
greater  than  the  row  number  of  the  old  position  or  (2)  the  row  number  of  the  new  position  is  the  same 
as  the  row  number  of  the  old  position  and  the  new  position  has  a  greater  column  number.  Similarly,  a 
position  Is  said  to  precede  the  active  position  If  (1)  the  row  number  of  the  position  is  less  than  the  row 
number  of  the  active  position  or  (2)  the  row  number  of  the  position  Is  the  same  as  the  row  number  of 
the  active  position  and  the  column  number  of  the  position  Is  smaller  than  the  column  number  of  the 
active  position. 


5.3.7.I.  Types,  subtypes  and  constants 

subtype  file_type  is  cais.  redefinitions,  filejtype; 
subtype  function_key_descriptor  is 

CAIS . IO_DEFIMITIONS .  FUNCTION_KEY_DESCRIPTOR ; 

subtype  POSITION  TYPE  is  CAIS .  ^DEFINITIONS .  POSITIONJTYPE; 

subtype  TABENUMERATION  is  CAIS . IO_DEFINITIONS . TABENUMERATION ; 

type  SELECT  ENUMERATION  is 

(FROM_ACTIVE_POSITION_TO_END . 

from-start_to_active-po5ition . 

ALLPOSITIONS) ; 

type  GRAPHIC  RENDITION  ENUMERATION  IS 
(PRIMARY  RENDITION, 

BOLD, 

FAINT, 

UNDERSCORE. 

SLOW_BLINX. 

RAPIDBLINK, 

REVERSEIMAGE) ; 

type  GRAPHICRENDITIONARRAY  is  array  (GRAPHIC  RENDITION  ENUMERATION) 
of  BOOLEAN; 

DEF AULT_GRAPHIC_RENDITI ON  :  Constant  GRAPHIC  RENDITION  ARRAY 

:=  (PRIMARYRENDITION  =>  TRUE,  BOLD.  REVERSEIMAGE  =>  FALSE); 

FILE_TYPE  describes  the  type  Tor  Hie  handles.  FUNCTION_KEY_ DESCRIPTOR  is  used  to 
obtain  Information  about  function  keys  read  from  a  terminal.  POSITION __ TYPE  describes  the  type 
of  a  position  on  a  terminal.  TAB _ ENUMERATION  Is  used  to  specify  the  kind  of  tab  stop  to  be  set. 
SELECT  _ENUMERATION  Is  used  In  ERASE  _  IN  _  DISPLAY  and  ERASE  _  IN  _LINE  to 
determine  the  portion  of  the  display  or  line  to  be  erased. 
GRAPIIIC_  RENDITION  _  ENUMERATION,  GRAPHIC  _  RENDITION  ARRAY,  and 

DEFAULT_GRAPHIC_RENDITION  are  used  to  determine  display  characteristics  of  printable 
characters. 


5.3.7. 2.  Setting  the  active  position 

procedure  set  position (terminal  :  in  file  type; 

POSITION  :  in  POSITION  TYPE) ; 


Purpose: 

This  procedure  advances  the  active  position  to  the  specified  POSITION  on  the  output  terminal 
file  Identified  by  TERMINAL. 
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Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

POSITION  Is  the  new  active  position  In  the  output  terminal  file. 


Exceptions: 

USE_ERROR  is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_K!ND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE_  ERROR 

Is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

LAYOUT  _  ERROR 

is  raised  if  the  position  does  not  exist  on  the  terminal. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  setposition (POSITION  :  in  POSITION  type) 

is 

begin 

SET  POSITION (CURRENT  OUTPUT.  POSITION); 
end  SET  POSITION; 


S.3.7.3.  Determining  the  active  position 

function  get_position (terminal  :  in  file_type) 
return  position_type  ; 

Purpose: 

This  function  returns  the  active  position  of  the  outpir  terminal  file  Identified  by  TERMINAL. 
Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  F!LE_KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERM!NAL_K!ND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  IN  FILE. 
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STATl'S_  ERROR 

is  raised  If  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

Additional  Interface: 

function  get  position  return  position  type 

is 

begin 

return  get_position(current_output) ; 

end  GET  POSITION; 


5.3.7.4.  Determining  the  aise  of  the  terminal 

function  TERHINALSIZE  (TERMINAL  :  in  FILE  TYPE) 
return  POsrriONjnrPE; 

Purpose: 

This  function  returns  the  maximum  row  and  maximum  column  of  the  output  terminal  file 
Identified  by  TERMINAL. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  a  terminal  file. 


Exceptions: 

USE_ERROR  is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  l\_FILK. 

STATUS_ ERROR 

Is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  terminalsize 

return  position  -type 

ia 

begin 

return  terninal  size (current  output)  ; 
end  terminal  size; 
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5.3.7. 5.  Setting  a  tab  atop 

procedure  set_tab (terminal  :  in  file_type; 

KIND  :  in  TAB_ENUMERATION  :=  HORIZONTAL); 


Purpose: 

This  procedure  establishes  a  horizontal  tab  stop  at  the  column  of  the  active  position  If  KIND  is 
HORIZONTAL,  or  a  vertical  tab  stop  at  the  row  of  the  active  position  If  KIND  Is  VERTICAL. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  a  terminal  file. 

KIND  Is  the  kind  (horizontal  or  vertical)  of  tab  to  be  set. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

is  raised  ir  the  rile  identified  by  TERMINAL  Is  of  mode  IN  FILE. 

STATUS _ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  la  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  set_tab(kind  :  in  tab_enumeration  :=  horizontal) 

is 

begin 

SET_TAB (CURRENT_QUTPUT .  KIND); 
end  set  TAB; 


5.3.7.O.  Clearing  a  tab  stop 

procedure  clear_tab  (terminal  :  in  file_type; 

KIND  :  in  T AB_ENUMERATI ON  :=  HORIZONTAL); 

Purpose: 

This  procedure  removes  a  horizontal  tab  stop  from  the  column  of  the  active  position  if  KIND  Is 
HORIZONTAL  or  a  VERTICAL  tab  stop  from  the  row  of  the  active  position  if  KIND  is 
VERTICAL. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  a  terminal  file. 
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KIND  is  the  kind  (horizontal  or  vertical)  of  tab  stop  to  be  removed. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TRRM1NAL_ KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL,  or  if  there  is 
no  tab  stops  of  the  designated  kind  at  the  active  position. 

MODE  ERROR 

Is  raised  if  the  file  Identified  by  TERMINAL  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  clear_tab(kind  :  in  tab_enuneration  :=  horizontal) 

is 

begin 

CLEARTAB (CURRENTOUTPUT ,  KIND); 
end  CLEAR  TAB; 


5. 3.7. 7.  Advancing  to  the  next  tab  position 

procedure  tab  (terminal  :  in  FILE  TTPE; 

KIND  :  in  TABENUKERATION  :=  HORIZONTAL; 

COUNT  :  in  POSITIVE  :=  1); 

Purpose: 

This  procedure  advances  the  active  position  COUNT  tab  stops.  Horizontal  advancement  causes 
a  change  in  only  the  column  number  of  the  active  position.  Vertical  advancement  causes  a 
change  in  only  the  row  number  of  the  active  position. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

KIND  is  the  kind  (horizontal  or  vertical)  of  tab  stop  to  be  advanced. 

COUNT  is  a  positive  integer  indicating  the  number  of  tab  stops  the  active  position  is  to 

advance. 

Exceptions: 

USE _ ERROR  is  raised  if  TERMINAL  Is  not  the  value  or  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_K!ND  of  the  flic 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  there  are 
fewer  than  COUNT  tab  stops  of  the  designated  kind  after  the  active  position. 


i  in 
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MODE _ ERROR 

Is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  IN_FII,K. 

STATUS _ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  tab(kind  :  in  tabenumeration  :=  horizontal: 
COUNT  :  in  POSITIVE  :=  1) ; 

is 

begin 

TAB (CURRENTOUTPUT .  KIND,  COUNT); 
end  TAB; 


S.3.7.8.  Sounding  a  terminal  bell 

procedure  bell  (Terminal  :  in  FILETTPE) ; 

Purpose: 

This  procedure  sounds  the  bell  (beeper)  on  the  terminal  represented  by  the  output  terminal  file 
identified  by  TERMINAL. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PACE  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MOI)E_  ERROR 

Is  raised  if  the  file  Identified  by  TERMINAL  Is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  bell 

is 

begin 

BELL(CURRENTOUTPUT) ; 
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end  BELL; 


5. 3. 7.0.  Writing  to  the  terminal 

procedure  pot  (terminal  :  in  pile_type; 

item  :  in  CHARACTER) : 


Purpose; 

This  procedure  writes  a  single  character  to  the  output  terminal  file  identified  by  TERMINAL 
and  advances  the  active  position  by  one  column. 

Parameter: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

ITEM  is  the  character  to  be  written. 


Exceptions: 

USE _  ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE _  KIND  or 
PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  Is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interfaces: 

procedure  put  (item  ;  in  character) 

is 

begin 

PUT (CURRENT_OUTPUT ,  ITEM) ; 
end  PUT; 

procedure  put  (term  inal  :  in  file  type; 

ITEM  :  in  STRING) 

la 

begin 

for  index  in  item -first  ..  item  last  loop 

PUT (TERMINAL,  ITEM (INDEX)) ; 

end  loop; 
end  PUT; 

procedure  put(item  :  in  string) 

ia 

begin 

PUT (CURRENT  OUTPUT.  ITEM); 
end  PUT; 
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Notes: 

After  a  character  is  written  in  the  rightmost  position  of  a  row,  the  active  position  is  the  first 
position  of  the  next  row. 

6.3.7.10.  Enabling  echo  on  a  terminal 

procedure  set_echo (terminal  :  in  file  type; 

TO  :  in  BOOLEAN  :=  TRUE); 


Purpose: 

This  procedure  establishes  whether  characters  which  appear  in  the  input  terminal  flic  identified 
by  TERMINAL  are  echoed  to  Its  associated  output  terminal  file.  When  TO  is  TRUE,  each 
character  which  appears  in  the  input  terminal  file  Is  echoed  to  the  output  terminal  flic.  When 
TO  is  FALSE,  each  character  which  appears  in  the  input  terminal  file  Is  not  echoed  to  Its 
associated  output  terminal  file. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  input  terminal  file. 

TO  indicates  whether  or  not  to  echo  Input  characters. 


Exceptions: 

USE _ ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FII,E_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL  _  KIND  of  the  file 
node  associated  with  the  rile  identified  by  the  parameter  TERMINAL. 

MODE_ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  OUT_FlLE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  set  echo  (to  :  in  boolean  :*  true) 

is 

begin 

SET  ECHO (CURRENT_INPUT ,  TO); 
end  SET  ECHO; 
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5.3.7.11.  Querying  echo  on  a  terminal 

function  echo  (tern  tn.m.  :  in  file_tyfe) 
return  boolean; 


Purpose: 

This  function  returns  TRUE  if  echo  is  enabled;  otherwise  it  returns  FALSE. 
Parameters: 

TERMINAL  is  an  open  file  handle  on  an  Input  terminal  file. 


Exceptions: 

USE _ ERROR  is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE _ KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  OUT _  FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  echo 

return  boolean 

is 

begin 

return  echo  (curreht_ihput)  ; 
end  echo; 


5.3.7.12.  Determining  the  number  of  function  keys 

function  maxihum_function_key  (terminal  :  in  file  type) 
return  natural; 


Purpose: 

This  function  returns  the  maximum  function  key  identification  number  that  can  be  returned  by 
a  GET  operation  In  the  Input  terminal  file  Identified  by  TERMINAL. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  input  terminal  file. 


Exceptions: 
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USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE  KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  identified  by  TERMINAL  is  of  mode  OUT  _  FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  bee;  use  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  kaximumfunctionjcey 
return  natural 

is 

begin 

return  maximum_function_key(currejit_input)  ; 
end  maximum  function  key; 


5.3.7.13.  Reading  a  character  from  a  terminal 

procedure  get  (terminal  :  In  filejtype: 

ITEM  out  CHARACTER; 

KEYS  out  FUNCTION_KEY_DESCRIPTQR)  ; 


Purpose: 

This  procedure  reads  either  a  single  character  Into  ITEM  or  a  single  function  key  Identification 
number  into  KEYS  from  the  input  terminal  file  identified  by  TERMINAL. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  input  terminal  file. 

ITEM  is  the  character  that  was  read. 

KEYS  describes  the  function  key  that  was  read. 


Exceptions: 

USE_ERROR  is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  F!LE_KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE  _  ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  OUT_FILE  or 
APPEND  FILE. 
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STATUS_ERR<  it 

h  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _ERROR 

Is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
nw  function  of  the  underlying  system. 


Additional  Interface: 

procedure  get  (item  .  out  character; 

KEYS  :  OUt  FUNCTION JCEY_DESCRIPTOR) 

is 

begin 

GET (CURRENT_INFUT ,  ITEM,  KEYS); 
end  GET; 


Notes; 

This  procedure  will  only  return  function  key  identification  numbers  In  KEYS  if  function  keys 
have  been  enabled  (see  Section  5.3.5.12).  Otherwise  the  characters  In  the  ASCII  character 
sequence  representing  the  function  key  will  appear  one  at  a  time  In  ITEM. 


5.3.7.14.  Reading  all  available  characters  from  t  terminal 

procedure  get  (terminal  :  in  FILE_TYPE; 

ITEM  OUt  STRING; 

LAST  OUt  NATURAL; 

KEYS  OUt  FUNCTION_KEY_DESCRIPTOR) ; 

Purpose: 

This  procedure  successively  reads  characters  and  function  key  Identification  numbers  Into  ITEM 
and  KEYS  respectively  until  either  all  positions  of  ITEM  or  KEYS  are  filled  or  there  are  no 
more  characters  available  In  the  Input  terminal  file.  Upon  completion,  LAST  contains  the  index 
of  the  last  position  in  ITEM  to  contain  a  character  that  has  been  read. 


Parameters: 

TERMINAL 

ITEM 

LAST 

KEYS 


Is  an  open  file  handle  on  an  Input  terminal  file. 

Is  a  string  of  the  characters  that  were  read, 
is  the  position  of  the  last  character  read  In  ITEM. 

is  the  description  of  the  function  key  identification  numbers  that  were  read. 


Exceptions: 

USE_ ERROR  is  raised  if  the  file  Identified  by  TERMINAL  is  not  the  value  of  the  predefined 
attribute  FILE_KIND  or  PAGE  Is  not  a  value  of  the  predefined  attribute 
TERM!NAL_KIND  of  the  file  node  associated  with  the  flic  Identified  by  the 
parameter  TERMINAL. 


MODE  ERROR 
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Is  raised  If  the  file  identified  by  TERMINAL  Is  of  mode  OUT_FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  get  (item  :  out  string; 

LAST  :  OUt  NATURAL; 

KEYS  :  out  FUNCTION  JCEYJJESCRIPTOR) 

is 

begin 

GET (CURRENTINPUT ,  ITEM.  LAST.  KEYS) ; 
end  GET; 


Notes: 

This  procedure  will  only  return  function  key  identification  numbers  In  KEYS  If  function  keys 
have  been  enabled  (see  Section  5.3.5.11).  Otherwise  the  characters  in  the  ASCII  character 
sequence  representing  the  function  key  will  appear  In  ITEM.  If  there  are  no  elements  available 
for  reading  from  the  input  terminal  file,  then  LAST  has  a  value  one  less  than  ITEM’FIRST  and 
FUNCTION  _  KEY  _COUNT(KEYS)  (see  Section  5.3.7.15)  Is  equal  to  zero. 

5.3.7.15.  Determining  the  number  of  function  keys  that  were  read 

function  FUNCTIONKEYCOUNT  (KEYS  :  in  FUNCTION  JCEYJJESCRIPTOR) 

return  natural; 


Purpose: 

This  function  returns  the  number  of  function  keys  described  In  KEYS. 
Parameters: 

KEYS  Is  the  function  key  descriptor  being  queried. 


Exceptions: 

None. 


5.3.7.10.  Determining  function  key  usage 


procedure  function jcey  (keys 

INDEX 

KEY_IDENTIFIER 

POSITION 


:  in  FUNCTION  JCEYJJESCRIPTOR; 

in  POSITIVE f 

out  POSITIVE; 
out  NATURAL)  ; 


Purpose: 

This  procedure  returns  the  Identification  number  of  a  function  key  and  the  position  In  the  string 
(read  at  the  same  time  as  the  function  keys)  of  the  character  following  the  function  key. 
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Parameters: 

KEYS  is  the  description  of  the  function  key  numbers  that  were  read. 

INDEX  is  the  index  in  KEYS  of  the  function  key  to  be  queried. 

KEY  _  IDENTIFIER 

is  the  identification  number  of  a  function  key. 

POSITION  is  the  position  of  the  character  read  after  the  function  key. 


Exceptions: 

CONSTRAINT  _  ERROR 

Is  raised  if  INDEX  is  greater  than  FUNCTION_  KEY_COUNT(KEYS)  . 

5.3.7.17.  Determining  the  name  of  a  function  key 

procedure  functioniceyjune (ternihal  :  in  file  type; 

KEY  JDENTIFIER  :  in  POSITIVE; 

KEY  JUKE  OUt  STRING; 

LAST  OUt  POSITIVE)  ; 

Purpose: 

This  function  returns  (in  KEY_NAME)  the  string  identification  or  the  function  key  designated 
by  KEY_ IDENTIFIER.  It  also  returns  the  index  of  the  last  character  of  the  function  key  name 
in  LAST. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  Input  terminal  file. 

KEY_  IDENTIFIER 

is  the  identification  number  of  a  function  key. 

KEY_NAME  is  the  name  of  the  key  designated  by  KEY _ IDENTIFIER. 

LAST  is  the  position  in  KEY_NAME  of  the  last  character  of  the  function  key  name. 


Exceptions: 

USE_ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND  or 
PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  OUT _  FILE  or 
APPEND  FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 
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DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

CONSTRAINT  _  ERROR 

Is  raised  if  the  value  of  KEY_  IDENTIFIER  is  greater  than 
MAXIMUM _ FUNCTION _KEY(TERMINAL)  or  the  string  identification  of  the 
function  key  sequence  is  longer  that  the  string  KEY_NAME. 


Additional  Interface: 

procedure  function_key_name  (key_identifier  :  in  positive; 

KEY_NAME  :  out  STRING; 

LAST  :  out  POSITIVE;) 

is 

begin 

FUNCTION  KEY  NAME (CURRENT  INPUT. 

KEY  IDENTIFIER,  KEYJIAME.  LAST); 
end  FUNCTION  KEY  NAME; 


5.3.7.18.  Deleting  characters 

procedure  DELETECHARACTER (TERMINAL:  in  FILE  TYPE; 

COUNT:  in  POSITIVE  :=  1) ; 


Purpose: 

This  procedure  deletes  COUNT  characters  on  the  active  line  starting  at  the  active  position  and 
advancing  toward  the  end  position.  Adjacent  characters  to  the  right  of  the  active  position  are 
shifted  left.  Open  space  on  the  right  is  filled  with  space  characters.  The  active  position  is  not 
changed. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

COUNT  is  the  number  of  characters  to  be  deleted. 

Exceptions: 

USE_ERROR  is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  If  the 
value  of  COUNT  is  greater  than  the  number  of  positions  In  the  active  line  Including 
and  following  the  active  position. 

MODE_ ERROR 

is  raised  if  TERMINAL  is  of  mode  IN_FILR. 

STATUS _ ERROR 

is  raised  if  the  file  Identified  by  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 
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Additional  Interface: 

procedure  delete_character  (count  :  in  positive  :=d 

is 

begin 

DEL£TE_CHARACTER (CURRENT  OUTPUT,  COURT) ; 
end  DELETE  CHARACTER; 


5.3.7.10.  Deleting  lines 

procedure  delete_liwe  (terminal  :  in  file_type; 

COURT:  in  POSITIVE : =1) ; 


Purpose: 

This  procedure  deletes  COUNT  lines  starting  at  the  active  position  and  advancing  toward  the 
end  position.  Adjacent  lines  are  shifted  from  the  bottom  toward  the  active  position.  Open  space 
at  the  bottom  of  the  display  is  filled  with  erased  lines.  The  active  position  Is  not  changed. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

COUNT  is  the  number  of  lines  to  be  deleted. 


Exceptions: 

USE _ ERROR  is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  KILE _  KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL,  or  ir  the 
value  of  COUNT  is  greater  than  the  number  of  rows  including  and  following  the 
active  position. 

MODE _ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  delete_l ike (coukt:  in  positive  :=  l) 

is 

begin 

DEL£TE_L I HE (CURR£HT_0UTPUT ,  COURT) ; 
end  DELETE_LIHE; 
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5.3.7.20.  Erasing  characters  in  s  line 

procedure  erase_character (terminal:  in  file  ttpe; 

COUNT:  in  POSITIVE  :=  1) ; 


Purpose: 

This  procedure  replaces  COUNT  characters  on  the  active  line  with  space  characters  starting  at 
the  active  position  and  advancing  toward  the  end  position.  The  active  position  is  not  changed. 

Parameters: 

TERMINAL  is  an  open  Die  handle  on  an  output  terminal  Hie. 

COUNT  Is  the  number  of  characters  to  be  erased 

Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  or  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  if  the 
value  of  COUNT  is  greater  than  the  number  of  positions  in  the  active  line  including 
and  after  the  active  position. 

MODE _ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  IN  _  FILE. 

STATUS _ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interaces: 

procedure  erase_character  ( count  :  in  positive  :=i) 

is 

begin 

ERASECHAJUCTER (CURRENTOUTPUT ,  COUNT); 
end  ERASE  CHARACTER; 


5.3.7.21.  Eraaing  characters  in  a  display 

procedure  erase_in_display (terminal:  in  filejtyfe; 

SELECTION:  in  SELECT_ENUKERATION) ; 

Purpose: 

This  procedure  erases  the  characters  In  the  display  as  determined  by  the  active  position  and  the 
given  SELECTION  (including  the  active  position).  After  erasure  erased  positions  have  space 
characters.  The  active  position  Is  not  changed. 

Parameters: 
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TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 
SELECTION  is  the  portion  of  the  display  to  be  erased. 


Exceptions: 

USE_ERROR  is  raised  If  TERMINAL  Is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL _  KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  If  the  file  Identified  by  TERMINAL  Is  of  mode  IN _  FILE. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  erase_in_display (selection  :  in  selectenumeration) 

ia 

begin 

EHASE_IN  DISPLAY (CURRENT  OUTPUT.  SELECTION) ; 
end  ERASE  IN  DISPLAY; 


5.3.7.22.  Erasing  characters  in  a  line 

procedure  erase_in_line (terminal:  in  file_type: 

SELECTION:  in  SELECT  ENUMERATION): 


Purpose: 

This  procedure  erases  the  characters  in  the  active  line  as  determii  od  by  the  active  position  and 
the  given  SELECTION  (including  the  active  position).  After  erasure  erased  positions  have  space 
characters.  The  active  position  Is  not  changed. 

Parameters: 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

SELECTION  Is  the  portion  of  the  line  to  be  erased. 

Exceptions: 

USE_ ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  if  the 
value  of  COUNT  is  greater  than  the  number  of  columns  including  and  following  the 
active  position. 
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MOI>E_  ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN _ FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEV1CE_  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  erase_in_line (selection:  in  select_enumeration) 

is 

begin 

ERASE_INJ.INE(CTJRRENT_OUTPUT,  SELECTION): 
end  ERASE  IN  LINE; 


5.3.7.23.  Inserting  space  characters  in  a  line 

procedure  insertspace (terminal:  in  file  type: 

COUNT:  in  POSITIVE  :=  1): 


Purpose: 

This  procedure  Inserts  COUNT  space  characters  Into  the  active  line  at  the  active  position.  The 
character  at  the  active  position  and  adjacent  characters  are  shifted  to  the  right.  The  COUNT 
rightmost  characters  on  the  line  are  lost.  The  active  position  Is  not  changed. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

COUNT  Is  the  number  of  space  characters  to  be  inset  ted. 

Exceptions: 

USE_ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  F1LE_KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL _ KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  If  the 
value  of  COUNT  Is  greater  than  the  number  of  columns  including  and  following  the 
active  position. 

MODE_ ERROR 

Is  raised  if  the  file  identified  by  TERMINAL  Is  of  mode  IN_FILE. 

STATUS _ ERROR 

Is  raised  if  TERMINAL  Is  not  an  open  (lie  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 
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Additional  Interface: 

procedure  insertspace (count:  in  positive  :=  1) 

is 

begin 

INSERT_SPACE(CURRENT_OUTPUT.  COUNT); 
end  INSERT  SPACE; 


5.3.7.24.  Inserting  blank  linea  in  the  output  terminal  file 

procedure  insert_line (terminal:  in  file_type; 

COUNT:  in  POSITIVE  :=  1); 


Purpose: 

This  procedure  inserts  COUNT  blank  lines  Into  the  output  terminal  file  at  the  active  line.  The 
lines  at  and  below  the  active  position  are  shifted  down.  The  COUNT  bottom  lines  of  the  display 
are  lost.  The  active  line  is  not  changed.  The  column  of  the  active  position  is  changed  to  one. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

COUNT  is  the  number  of  blank  lines  i<>  be  Inserted. 

Exceptions: 

USE_ERROR  is  raised  ir  TERMINAL  Is  not  the  value  or  the  predenned  attribute  FILE_KIND 
or  PAGE  Is  not  a  value  of  the  predePned  attribute  TERMINAL _ KIND  or  the  nie 
node  associated  with  the  nie  Identined  by  the  parameter  TERMINAL,  or  the  value 
of  COUNT  is  greater  than  the  number  of  rows  including  and  following  the  active 
position. 

MODE_ ERROR 

Is  raised  if  the  nie  identined  by  TERMINAL  is  of  mode  IN _  FILE. 

STATUS _ ERROR 

Is  raised  If  TERMINAL  Is  not  an  open  nie  handle. 

DEV1CE_  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  insertline  (count:  in  positive^  D 

is 

begin 

INSERT_LINE (CURRENT  OUTPUT.  COUNT); 
end  INSERT  LINE; 
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5.3.7.25.  Determining  graphic  rendition  support 

function  graphic_rendition_supp{3RT(terkikal:  in  file  type; 

RENDITIOM :  in  GRAPHIC  RENDITION  ARRAY) 


return  boolean; 


Purpose; 

This  function  returns  TRUE  If  the  RENDITION  of  combined  graphic  renditions  Is  supported  by 
the  physical  terminal  associated  with  the  output  terminal  file  Identified  by  TERMINAL; 
otherwise  it  returns  FALSE. 

Parameters; 

TERMINAL  is  an  open  file  handle  on  an  output  terminal  file. 

RENDITION  is  a<comblnation  of  graphic  renditions. 

Exceptions; 

USE _  ERROR  is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE _  KIND 
or  PAGE  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL,  or  If  the 
selected  graphic  renditions  are  not  supported  by  the  physical  terminal  associated 
with  the  output  terminal  file  Identified  by  TERMINAL. 

MODE_ ERROR 

is  raised  if  the  rile  Identified  by  TERMINAL  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  graphic  rendition_support (rendition  : 

in  GRAPHIC_RENDITION_ARRAY) 

return  boolean 

ia 

begin 

return  graphic_rendition_support(current_output.  rendition); 
end  graphic  rendition  support; 


5.3.7.20.  Selecting  the  graphic  rendition 

procedure  select  graphic  rendition (terminal;  in  file_type; 

RENDITION:  in  GRAPHIC_RENDITIQN_ ARRAY 

:=  DEFAULT  GRAPHIC  RENDITION); 


Purpose: 

This  procedure  sets  the  graphic  rendition  for  subsequent  characters  to  be  output  to  the  output 
terminal  file. 
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Parameters: 

TERMINAL  Is  an  open  file  handle  on  an  output  terminal  file. 

RENDITION  Is  the  graphic  rendition  to  be  used  In  subsequent  output  operations. 

Exceptions: 

USE_ERROR  Is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  PAGE  is  not  a  value  of  the  predefined  attribute  TERMINAL  _  KIND  of  the  file 
node  associated  with  the  file  Identified  by  the  paramet*  r  TERMINAL,  or  if  the 
selected  graphic  renditions  are  not  supported  by  the  ph  sical  terminal  associated 
with  i  he  output  terminal  flic  identified  by  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  of  mode  IN  _ FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

procedure  SELECT_OTAPHIC_RENDITION (RENDITION  :  in 

GRAPHICRENDITION  ARRAY  :  = 
DEFAULT  GRAPHIC  RENDITION) 

is  -  - 

begin 

SELECT_GRAPHIC_RENDITION<CURRENT_OUTPUT,  RENDITION); 

end  select  graphic  rendition; 


5.3.8.  Package  FORM  TERMINAL 

This  package  provides  the  functionality  of  a  form  terminal  (e.g.,  an  IBM  327x  terminal).  A  form 
terminal  consists  of  a  single  device  (Inasmuch  as  a  programmer  Is  concerned). 

The  scenario  for  usage  of  a  form  terminal  has  two  active  agents:  a  process  and  a  user.  Each 
interaction  with  the  form  terminal  consists  of  a  three  step  sequence.  First,  the  process  creates  and 
writes  a  form  to  the  terminal.  Second,  the  user  modifies  the  form.  Third,  the  process  reads  the 
modified  form. 

A  form  is  a  two-dimensional  matrix  of  character  positions.  The  rows  of  a  form  are  indexed  by 
positive  numbers  starting  with  row  one  at  the  top  of  the  display.  The  columns  of  a  form  are  Indexed 
by  positive  numbers  starting  with  column  one  at  the  left  side  of  the  form.  The  position  identified  by 
row  one,  column  one,  Is  called  the  start  position  of  the  form.  The  position  with  the  highest  row  and 
column  Index  term  is  called  the  end  position  of  the  form. 

The  position  at  which  an  operation  is  to  be  performed  Is  called  the  active  position.  The  active 
position  Is  said  to  advance  toward  the  end  position  of  the  form  when  the  Indices  of  its  position  are 
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Incremented.  The  column  Index  Is  incremented  until  It  attains  the  highest  value  permitted  for  the 
form.  The  next  position  Is  determined  by  Incrementing  the  row  Index  of  the  active  position  and 
resetting  the  column  Index  to  1. 

A  form  is  divided  into  qualified  areas.  A  qualified  area  Identifies  a  contiguous  group  of  positions  that 
share  a  common  set  of  characteristics.  A  qualified  area  begins  at  the  position  designated  by  an  area 
qualifier  and  ends  at  the  position  preceding  the  next  area  qualifier  toward  the  end  of  the  form. 
Depending  on  the  form,  the  position  of  the  area  qualifier  may  or  may  not  be  considered  to  be  in  a 
qualified  area.  The  characteristics  of  a  qualified  area  consist  of  suc  h  things  as  protection  (from 
modification  by  the  user),  display  renditions  (e.g.,  intensity),  and  permissible  values  (e.g..  numeric 
only,  alphabetic  only).  Each  position  in  a  qualified  area  contains  a  single  printable  ASCII  character. 

5. 3. 8.1.  Types  and  subtypes 

type  AREAINTENSITY  is 
(NONE 
NORMAL. 

HIGH) ; 

type  AREAPROTECTION  is 
(UNPROTECTED . 

PROTECTED) ; 

type  AREAINPUT  is 

(GRAPHICCHARACTERS , 

NUMERICS. 

ALPHABETIC^) ; 

type  AREA  VALUE  is 
(NO  FILL, 

FILL  WITH  ZEROES, 

FILL_Wrnf  SPACES)  ; 

type  FORM  TYPE 
(ROW 
COLUMN 

AREAJJUALIFIERREQUIRESSPACE 
is  private; 

subtype  filetype  is  cais.io_definitions.file_type; 
subtype  printable_characters  is  character  range  *  * 

AREA _  INTENSITY  indicates  the  Intensity  at  which  the  characters  In  the  area  should  be  displayed 
(NONE  indicates  that  characters  are  not  displayed).  AREA_ PROTECTION  specifies  whether  the 
user  can  modify  the  contents  of  the  area  when  the  form  has  been  activated.  AREA _  INPUT  specifies 
the  valid  characters  that  may  be  entered  by  the  user;  GRAPHIC  _ CHARACTERS  indicates  that  any 
printable  character  may  be  entered.  AREA _ VALUE  indicates  the  initial  value  that  the  area  should 
have  when  activated;  NO _ FILL  Indicates  that  the  value  has  been  specified  by  a  previous  PUT 
statement.  FORM_TYPE  describes  characteristics  of  forms.  FILE_TYPE  describes  the  type  for 
file  handles.  PRINTABLE_CIIARACTERS  describes  the  characters  that  can  be  output  to  a  form 
terminal. 


POSITIVE; 

POSITIVE; 

BOOLEAN) 
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5.3. 8. 2.  Determining  the  number  of  function  keys 

function  maxi«um_function_key(termihal:  in  file_type) 
return  natural; 


Purpose: 

This  function  returns  the  maximum  function  key  Identifier  that  can  be  returned  by  the  function 
TERMINATION _  KEY  (see  Section  5.3.8.13). 

Parameters; 

TERMINAL  Is  an  open  file  handle  on  a  terminal  file. 


Exceptions: 

USE_ERROR  Is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  FORM  is  not  a  value  of  the  predefined  attribute  TKRMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 

MODE _ ERROR 

is  raised  if  the  file  identified  by  TERMINAL  is  or  mode  OUT  _  FILE  or 
APPEND  _  FILE. 

STATUS _ ERROR 

is  raised  If  TERMINAL  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  maximumfunctionkey  return  natural 

ia 

begin 

return  UAXIMUM_nWCTXON_KEY(CURRENT_INPUT)  ; 
end  MAXIMUM  FUNCTION  KEY; 


5.3.8.3.  Defining  a  qualified  area 

procedure  define_qualified_area 
(FORM:  in  out  F0RM_TYPE; 


INTENSITY: 

in 

AREA_INTENSITY  :=  NORMAL; 

PROTECTION: 

in 

AREA JPROTECTI ON  :=  PROTECTED; 

INPUT: 

in 

AREA~INPUr  :=  CRAPHIC_CHARACTERS; 

VALUE: 

in 

AAEA~VALUE  :=  NO  FILL); 

Purpose: 

This  procedure  places  an  area  qualifier  with  the  designated  attributes  at  the  active  position  of 
the  form.  A  qualified  area  consists  of  the  character  positions  between  two  area  qualifiers.  The 
area  is  qualified  by  the  area  qualifier  that  precedes  the  area.  A  qualified  area  may  or  may  not 
include  the  position  of  Its  area  qualifier. 
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Parameters: 

FORM  Is  the  form  on  which  the  qualified  area  Is  being  defined. 

INTENSITY  Indicates  the  Intensity  at  which  the  qualified  area  Is  to  be  displayed. 
PROTECTION  Indicates  the  protection  for  the  qualified  area. 

INPUT  Indicates  the  permissible  input  characters  for  the  qualified  area. 

VALUE  Indicates  the  Initial  value  of  the  qualified  area. 

Exceptions: 

STATUS _ ERROR 

Is  raised  if  the  active  position  is  already  defined  as  an  area  qualifier. 

5.3.8.4.  Removing  an  area  qualifier 

procedure  remove jutEA_quALiFiER (form:  in  out  formtype)  ; 

Purpose: 

This  procedure  removes  an  area  qualifier  from  the  active  position  of  the  form. 
Parameters: 

FORM  is  the  form  from  which  the  qualified  area  is  to  be  removed. 

Exceptions: 

USE  _  ERROR  Is  raised  If  the  active  position  does  not  have  an  area  qualifier. 

STATUS _ ERROR 

Is  raised  if  the  active  position  does  not  contain  an  area  qualifier. 

5.3.8.5.  Changing  the  active  position 

procedure  set_positiom(form:  in  out  form  type; 

POSITION :  in  POSITION_TYPE) ; 

Purpose: 

This  procedure  indicates  the  position  on  the  form  that  is  to  become  the  active  position. 
Parameters: 

FORM  Is  the  form  on  which  to  change  the  active  position. 

POSITION  Is  the  new  active  position  on  the  form. 

Exceptions: 

LAYOUT  _  ERROR 

Is  raised  If  POSITION  does  not  Identify  a  position  in  FORM. 
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5. 3.8.6.  Moving  to  the  next  qualified  area 

procedure  next  jjualifiedarea  (form:  in  out  form_type; 

COURT:  in  POSITIVE  :=  1); 

Purpose: 

This  procedure  advances  the  active  position  COUNT  qualified  areas  toward  the  end  of  the  form. 
Parameters: 

FORM  is  the  form  on  which  the  active  position  is  being  advanced. 

COUNT  Is  the  number  of  qualified  areas  the  active  position  Is  to  be  advanced. 

Exceptions: 

USE_  ERROR  is  raised  if  FORM  has  fewer  than  COUNT  qualified  areas  after  the  active  position. 


5. 3. 8. 7.  Writing  to  a  form 

procedure  put  (form:  in  out  FORMTYPE; 

ITEM:  in  PRINTABLECHARACTER) ; 

Purpose: 

This  procedure  places  ITEM  at  the  active  position  of  FORM  and  advances  the  active  position 
one  position  toward  the  end  position.  If  the  active  position  Is  the  end  position,  the  active 
position  is  not  changed. 

Parameters: 

FORM  Is  the  form  being  written. 

ITEM  is  the  character  to  be  written  to  the  form. 


Exceptions: 

USE_  ERROR  is  raised  If  the  active  position  contains  an  area  qualifier  and 

AREA _ QUALIFIER  _  REQUIRES  SPACE  of  FORM  was  set  to  TRUE. 


Additional  interface: 

procedure  put  (form:  in  out  formjtype; 

ITEM:  in  STRING) 

is 

begin 

for  INDEX  in  ITEM ’FIRST  .  .  ITEM ’LAST  loop 
PUT (FORM.  ITEM (INDEX)) ; 
end  loop; 
end  PUT; 
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5.3. 8. 8.  Erasing  >  qualified  ares 

procedure  erase_area(form:  in  out  form_type): 

Purpose: 

This  procedure  places  space  characters  In  all  positions  of  the  area  In  which  the  active  position  of 
the  form  is  located. 

Parameters: 

FORM  is  the  form  on  which  the  qualified  area  Is  being  erased. 


Exceptions: 

STATUS _ ERROR 

Is  raised  if  no  area  qualifiers  have  been  defined  for  FORM. 

S.3.8.0.  Erasing  a  form 

procedure  erase_form(form-.  in  out  form  type): 

Purpose: 

This  procedure  removes  all  area  qualifiers  and  places  SPACE  characters  In  all  positions  of  the 
form. 

Parameters: 

FORM  Is  the  form  to  be  erased. 


Exceptions: 

None. 


5.3.8.10.  Activating  a  form  on  a  terminal 

procedure  activate  (terminal:  in  file_type; 

FORM:  in  out  F0RM_TrPE) ; 

Purpose: 

This  procedure  activates  the  form  on  the  terminal.  The  contents  of  the  terminal  file  Is  modified 
to  reflect  the  contents  of  the  form.  When  the  user  of  the  terminal  enters  a  termination  key,  the 
modified  contents  of  the  terminal  file  Is  copied  back  to  the  form  and  returned.  This  operation 
may  not  result  in  the  modification  of  protected  areas. 

Parameters: 

TERMINAL  Is  an  open  file  handle  on  a  terminal  file. 

FORM  Is  the  form  to  be  activated. 

Exceptions: 

USE_ERROR  Is  raised  If  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_KIND 
or  FORM  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  file 
node  associated  with  the  file  identified  by  the  parameter  TERMINAL. 
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STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

5.3.8.11.  Reading  from  a  form 

procedure  set  (form:  in  out  formjtype; 

ITEM:  out  PRINTABLE_CHARACTER) ; 

Purpose: 

This  procedure  reads  a  character  from  FORM  at  the  active  position  and  advances  the  active 
position  forward  one  position  (unless  the  active  position  is  the  end  position).  An  area  qualifier 
(on  a  form  on  which  the  area  qualifier  requires  space)  is  read  as  the  SPACE  character. 


Parameters: 

FORM 

is  the  form  to  be  read. 

ITEM 

is  the  character  that  was  read. 

Exceptions: 

None. 

Additional  Interface: 

procedure  get  (form:  in  out  FORMJTYPE; 

ITEM:  out  STRING) 

it 

begin 

for  INDEX  in  ITEM  "FIRST  .  .  ITEM  "LAST  loop 
GET (FORM.  ITEM (INDEX)) ; 
end  loop; 
end  GET; 


5.3.8.12.  Determining  changes  to  a  form 

function  is_form_updated  (form  :  in  formjtype) 
return  boolean; 

Purpose: 

This  function  returns  TRUE  if  the  value  of  any  position  on  the  form  was  modified  during  the 
last  activate  operation  In  which  the  form  was  used;  otherwise  It  returns  FALSE. 

Parameters: 

FORM  Is  the  form  to  be  queried. 


Exceptions: 

None. 
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5.3.8.13.  Determining  the  termination  key 

function  TERMINATION KEY  (FORK:  in  FORM_TYPE) 

return  natural; 

Purpose: 

This  function  returns  a  number  that  indicates  which  (implementation-dependent)  key 
terminated  the  ACTIVATE  procedure  for  the  FORM.  A  value  of  zero  Indicates  the  normal 
termination  key  (e.g..  the  ENTER  key). 

Parameters: 

FORM  is  the  form  to  be  queried. 


Exceptions: 

None. 


5.3.8.14.  Determining  the  size  of  a  form 

function  form  size  (form:  in  form  type) 
return  position  type; 


Purpose: 

This  function  returns  the  position  of  the  last  column  of  the  last  row  of  the  form. 


Parameters: 

FORM  is  the  form  to  be  queried. 


Exceptions: 

None. 


5.3.8.15.  Determining  the  sise  of  a  terminal 

function  terminal_size (terminal:  in  file_type) 
return  POSITION  TYPE; 


Purpose: 

This  function  returns  the  position  of  the  last  column  of  the  last  row  of  the  terminal  file. 
Parameters: 

TERMINAL  is  an  open  file  handle  on  a  terminal  file. 


Exceptions: 

U8E_KRROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  I'll, E_  K  INI) 
or  FORM  Is  not  a  value  of  the  predefined  attribute  TERMINAL_KINI>  of  the  file 
node  associated  with  the  file  identified  by  the  paramete.  TERMINAL. 

STATUS _ ERROR 

Is  raised  If  TERMINAL  is  not  an  open  file  handle. 
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DEVICE  _  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  termi  nal_s  i ze 

return  position_type 

is 

begin 

return  terminal_size(currej(t_output)  ; 
end  TERMINAL  SIZE: 


5.3.8.16.  Determining  if  the  area  qualifier  requires  space  in  the  form 

function  AREA_QUALIFIER_REIJUIR£S_SPACE  (FORM :  in  FQRM  TYPE) 
return  boolean; 


Purpose: 

This  function  returns  TRUE  if  the  area  qualifier  requires  space  in  the  form;  otherwise  it  returns 
FALSE. 


Parameters: 

FORM  Is  the  form  to  be  queried. 

Exceptions: 

None. 


5.3.8.17.  Determining  if  the  area  Qualifier  requires  apace  on  a  terminal 

function  area_qualifier_requires_Space (terminal:  in  file  type) 
return  BOOLEAN; 


Purpose: 

This  function  returns  TRUE  if  the  area  qualifier  requires  space  on  the  physical  terminal 
associated  with  the  terminal  file  Identified  by  TERMINAL;  otherwise  It  returns  FALSE. 

Parameters: 

TERMINAL  Is  a  t  open  file  handle  on  a  terminal  file. 


Exceptions: 

USE_ ERROR  is  raised  if  TERMINAL  is  not  the  value  of  the  predefined  attribute  FILE_K!NI) 
or  FORM  is  not  a  value  of  the  predefined  attribute  TERMINAL_KIND  of  the  rile 
node  associated  with  the  file  Identified  by  the  parameter  TERMINAL. 

STATUS _ ERROR 

is  raised  if  TERMINAL  is  not  an  open  file  handle. 

DEVICE  ERROR 
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is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Additional  Interface: 

function  area_qualifier_requires_space 
return  boolean 

is 

begin 

return  area_qualifier_requires_space  (ctjrrent_output)  ; 
end  areajjualifier  requir£s_space;_ 


5.3.9.  Package  MAGNETIC _ TAPE 

This  package  provides  Interfaces  for  the  support  of  Input  and  output  opera' ions  on  both  labeled  and 
uniabeled  magnetic  tapes.  Interfaces  for  labeled  tapes  are  designed  with  careful  consideration  of  level 
II  of  the  [ANSI  78]  standard.  These  interfaces  only  support  single-volume  magnetic  tape  files. 

To  use  a  tape  drive,  a  file  handle  on  the  file  representing  the  tape  drive  must  be  obtained  (see  OPEN 
In  Section  5.3.4. 3).  The  first  time  a  tape  is  used,  It  must  be  Initialized  either  ;is  a  labeled  tape  or  as  an 
unlabeled  tape.  All  initialized  tapes  may  be  loaded  as  unlabeled  tapes;  however,  only  initialized  labeled 
tapes  may  be  loaded  as  labeled  tapes.  Once  a  tape  has  been  loaded.  CAIN. TEXT _IO  routines  are 
used  to  get  Information  to  and  from  the  tape. 

When  information  transfer  is  completed,  the  tape  Is  unloaded  and  dismounted  using  the  UNLOAD 
and  DISMOUNT  procedures. 

Once  a  tape  Is  dismounted,  another  tape  may  be  mounted.  When  the  user  Is  finished  utilizing  the 
drive,  he  closes  the  file  handle  on  the  file  representing  the  tape  on  the  drive  (see  Section  5.3.4). 

Magnetic  tape  drive  files  can  only  be  created  by  the  implementation.  Implementation-defined  (lie 
characteristics  must  be  supported  by  the  Implementation  and  will  Include  the  densities  and  block  sizes 
supported  by  the  tape  drive,  whether  or  not  a  tape  is  mounted  on  the  drive  and  whether  the  tape  was 
loaded  as  a  labeled  or  unlabeled  tape.  Each  block  of  a  file  may  be  terminated  by  zero  or  more  fill 
characters. 

An  uniabeled  tape  is  read  according  to  the  format: 


BOT  file  *  file  *  ...  *  file  ** 


where  *  represents  a  tape  mark,  **  represents  the  logical  end  or  tape,  and  BOT  is  the  beginning  of 
the  tape.  For  the  CAIS,  a  file  on  a  magnetic  tape  is  either  a  text  file  or  a  label  group.  A  labeled  tape 
may  be  mounted  as  an  uniabeled  tape,  which  causes  each  label  group  to  be  considered  as  a  file.  A 
label  group  can  be  one  of  the  following:  a  volume  header  label  and  a  file  header  label,  or  a  file  header 
label,  or  an  end-of-flle  label. 

A  labeled  tape  is  read  according  to  the  format: 
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BOT  VOLi  HDR  *  nie  *  EOF  *  HDR  *  Hie  «  EOF  *...*  HDR  *  Hie  *  EOF** 


where  *  represents  a  tape  mark,  **  represents  the  logical  end  of  tape,  BOT  is  the  beginning  of  the 
tape,  VOLI  Is  the  volume  header  label,  HDR  Is  the  file  header  label,  and  EOF  Is  the  end-of-flle  label. 


5.3.9.I.  Types  and  subtypes 

type  tape_position  is 
(BEGINNING  OF_TAPE, 
PHYSICAL  lND-0F  TAPE, 
TAPE  MARK, 

OTHER)  ; 


subtype  reel_kame  is  STRING; 

subtype  volumestring  is  STRING  (l .  .8) ; 

subtype  file  string  is  string  (l.  .17); 

subtype  label  string  is  string  (i..so); 

subtype  file_type  is  cais.io_definitions. file  type; 

TAPE_POSITION  describes  the  position  of  the  tape  on  the  tape  drlvi :  a  value  of  TAPE _ MARK 
means  that  the  tape  Is  positioned  just  after  a  tape  mark.  That  is,  a  read  in  this  position  will  read  the 
next  file  or  label.  A  read  starting  In  position  TAPE_MARK  will  only  road  a  tape  mark  if  there  are 
two  consecutive  tape  marks  on  the  tape  at  this  location. 

REEL _  NAME  describes  the  type  used  for  the  external  name  of  a  tape  'i.e,  the  name  written  on  the 
tape  container). 

VOLUME_  STRING  and  FILE_STRING  both  have  the  syntax  of  an  Ada  identifier. 
LABEL_STRING  describes  the  type  used  for  reading  volume  header  labels,  file  header  labels  and 
end-of-flle  labels.  FILE_TYPE  describes  the  type  for  file  handles,  whi<  h  are  used  for  controlling  all 
operations  on  tape  drives. 

S.3.9.2.  Mounting  a  tape 

procedure  mount (tape_drive :  in  file_type; 

TAPE~  NAME :  in  REEL  NAME; 

DENSITY:  in  POSIT'.'  • )  ; 


Purpose: 

This  procedure  generates  an  implementation-d  'fined  request  that  the  tape  whose  external  name 
Is  TAPE_NAME  be  mounted  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE_DRIVE.  It  also  requests  that  the  tape  drive  density  be  set  to  DENSITY.  Following 
completion  of  the  requested  operations,  the  function  IS_MOUNTED(TAPE_ DRIVE)  will 
return  TRUE. 

Parameters: 

TAPE  _  DRIVE 

Is  an  open  flic  handle  on  the  file  representing  the  tape  drive. 

TAPE  _  NAME 

is  an  external  name  which  Identifies  the  tape  to  be  mot  nted  on  the  tape  drive. 
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DENSITY  Is  the  density  In  characters  per  Inch  (e.g.,  800,  1600,  6250). 


Exceptions: 

USE_ERROR  is  raised  if  MAGNETIC_TAPE  is  not  the  value  of  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  Identified  by  TA!’E_DRrVE  or  If 
IS  _ MOUNTED( TAPE _ DRIVE)  la  TRUE  at  the  time  of  the  call. 

STATUS  ERROR 

Is  raised  If  TAPE  _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  this  operation  cannot  be  completed  because  of  a  malfunction  of  the 
underlying  system. 

5.3.O.3.  Loading  an  unlabeled  tape 

procedure  lqad  umlabeled (tape_drive  :  in  file_type; 

DENSITY :  in  POSITIVE; 

BLOCXSIZE:  in  POSITIVE) : 

Purpose: 

This  procedure  loads  the  tape  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE__  DRIVE.  The  tape  is  positioned  at  the  beginning  of  tape.  The  DENSITY  is  validated 
against  the  settings  of  the  tape  drive.  The  block  size  for  subsequent  reads  and  writes  is  set  to 
the  value  of  BLOCK  ___  SIZE.  Following  completion  of  this  procedure,  the  function 
IS  _  LOADED(TAPE  _  DRIVE)  will  return  true. 

Parameters: 

TAPE_DRIVE  Is  an  open  file  handle  on  the  file  representing  the  drive. 

DENSITY  Is  the  density  in  characters  per  inch  (e.g.,  800,  1600,  6250)  at  which  the  tape  is  to 
be  read  or  written. 


BLOCK  _  SIZE  Is  the  size  of  each  data  block  which  is  to  be  read  from  or  written  to  the  file 
identified  by  TAPE  DRIVE. 


Exceptions: 

USE_ ERROR  is  raised  If  IS_LOADED(TAPE_DRIVE)  is  TRUE  or 
IS _MOUNTED(TAPE_  DRIVE)  is  FALSE  at  the  time  of  the  call,  or  If  DENSITY 
is  not  the  same  as  the  density  of  the  tape  drive,  or  if  the  block  size  cannot  be 
supported  by  the  tape  drive. 

STATUS _ ERROR 

is  raised  If  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system  or  if  the  tape  Is  uninitialized. 
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5.3.9. 4.  Initialising  an  unlabeled  tape 


Purpose: 


procedure  initialize_uxlabeled  (tape_drive  : 

DENSITY: 
BLOCK  SIZE: 


in  FILETYPE; 
in  POSITIVE; 
in  POSITIVE); 


This  procedure  Initializes  the  tape  which  Is  mounted  on  the  -?pe  drive  represented  by  the  file 
identified  by  TAPE  _  DRIVE.  The  tape  drive  must  have  been  mounted  but  not  loaded.  If  the 
tape  is  not  positioned  at  the  beginning  of  tape,  then  the  tape  is  rewound  to  it.  Two  adjacent 
tape  marks  are  written  following  the  beginning  of  tape  mark. The  DENSITY  Is  validated  against 
the  settings  of  the  tape  drive.  The  block  sign  for  subsequent  reads  and  writes  is  set  to  the  value 
of  BLOCK _ SIZE.  The  tape  Is  positioned  at  the  beginning  of  the  tape.  Initialization  places  the 
logical  end  of  tape  at  the  beginning  of  the  tape.  The  resulting  tape  is  an  initialized  unlabeled 
tape. 


Parameters: 

TAPE_DRIVE  is  an  open  file  handle  on  the  file  representing  the  drive. 

DENSITY  Is  the  density  in  characters  per  inch  (e.g.,  800,  1600,  6250) 

BLOCK_SIZEis  the  size  of  each  data  block  which  Is  to  be  read  from  or  written  to  the  file 
Identified  by  TAPE  DRIVE. 


Exceptions: 

USE_ ERROR  is  raised  ir  MAGNETIC _ TAPE  is  not  the  value  of  the  attribute  FILE _  KIND  of 
the  node  associated  with  the  rile  Identified  by  TAPE_ DRIVE,  or  DENSITY  is  not 
the  same  as  the  density  of  the  tape  drive,  or  ir  the  block  size  cannot  be  supported 
by  the  tape  drive. 

MODE _ ERROR 

Is  raised  if  the  rile  identified  by  TAPE_  DRIVE  is  of  mode  IN _ FILE. 

STATUS _ ERROR 

is  raised  if  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Notes: 

The  first  file  Is  written  immediately  following  the  beginning  of  tape  mark,  overwriting  the  two 
tape  marks  written  at  Initialization. 


5.3.9. 5.  Loading  a  labeled  tape 

in  FILE  TYPE; 
in  VOLUME_STRING ; 
in  POSITIVE; 
in  POSITIVE) ; 


procedure  load_l*beled  (tape_drive  : 

VOLUNE_IDFNTIFIER : 
DENSITY: 

BLOCK  SIZE: 
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Purpose: 

This  procedure  loads  the  labeled  tape  on  the  tape  drive  represented  by  the  nie  identified  by 
TAPE_DRIVE.  It  checks  to  see  that  the  first  block  on  the  volume  is  a  volume  header  label 
("VOLl").  The  VOLUME_IDENTlFIER  In  the  parameter  list  must  match  the  volume 
identifier  in  the  volume  header  label  on  the  tape.  The  tape  is  positioned  at  the  beginning  of 
tape.  The  DENSITY  is  validated  against  the  settings  of  the  tape  drive.  The  block  size  for 
subsequent  reads  and  writes  Is  set  to  the  value  of  BLOCK_SIZE.  Following  completion  of  this 
procedure,  the  function  IS _  LO ADED( TAPE _ DRIVE)  (see  Section  5.3. 9. 6)  will  return  TRUE. 

Parameters: 

TAPE_ DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

VOLUME_  IDENTIFIER 

Is  the  name  which  identifies  the  volume. 

DENSITY  Is  the  density  in  characters  per  Inch  (e.g.,  800,  1600,  6250)  at  which  the  tape  is  to 
be  read  or  written. 

BLOCK _  SIZE  Is  the  size  of  each  data  block  which  is  to  be  read  from  or  written  to  the  file 
Identified  by  TAPE_ DRIVE. 


Exceptions: 

USE  _  ERROR  Is  raised  If  IS _  LOADED( TAPE _ DRIVE)  is  TRUE  or 

IS  _MOUNTED(TAPE_  DRIVE)  is  FALSE  prior  to  the  call,  or  the 
VOLUME _ IDENTIFIER,  does  not  match  the  volume  Identifier  In  the  volume 
header  label  on  the  tape,  or  if  the  tape  Is  unlabeled.  USE_  ERROR  is  also  raised  if 
the  block  size  cannot  be  supported  by  the  tape  drive  or,  If  DENSITY  is  not  the 
same  as  the  density  of  the  tape  drive. 


STATUS _ ERROR 

Is  raised  If  TAPE_DRIVE  is  not  an  open  nie  handle. 

DEVICE  _  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


5.3.0. 0.  Initialising  a  labeled  tape 

in  FILETYPE; 
in  vouiitE_STRiMG: 
in  POSITIVE; 

in  positive; 

in  CHARACTER : = '  •) ; 


procedure  iNiTiALiZE_LABEi.ro  (tape  drive  : 

VOLUVE_IDENTIFIER : 
DENSITY: 
BLOCX_SIZE: 
ACCESSIBILITY : 


Purpose: 

This  procedure  initializes  the  tape  which  is  mounted  on  the  tape  drive  represented  by  the  file 
identified  by  TAPE_DRIVE.  The  tape  drive  must  have  been  mounted  but  not  loaded.  If  the 
tape  Is  not  positioned  at  the  beginning  of  tape,  then  the  tape  Is  rewound  to  It.  A  volum  header 
label  is  written,  followed  by  two  tape  marks.  The  tape  Is  positioned  following  the  volume  h  :idcr 
label.  Initialization  places  the  logical  end  of  tape  after  the  volume  header  label.  The  DENSITY 
Is  validated  against  the  settings  of  the  tape  drive.  The  block  size  for  subsequent  reads  and 
writes  is  set  to  the  value  of  BLOCK  _SIZE.  The  resulting  tape  Is  an  Initialized  labeled  tape. 
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Parameters: 

TAPE  _  DRIVE  is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

VOLUME  _  IDENTIFIER 

Is  a  six-character  string  giving  the  volume  name. 

DENSITY  is  the  density  In  characters  per  Inch  (e.g.,  800,  1600,  6250)  at  which  the  tape  is  to  be 
read  or  written. 

BLOCK_SIZEis  the  size  of  each  data  block  which  is  to  be  read  from  or  written  to  the  file 
Identified  by  TAPE _  DRIVE. 

ACCESSIBILITY 

is  a  character  representing  restrictions  on  access  to  the  tape,  in  accordance  with 
[ANSI  78);  a  SPACE  Indicates  no  access  control. 


Exceptions: 

USE_ ERROR  is  raised  if  MAG NETIC_ TAPE  Is  not  the  value  or  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  identified  by  TAPE  _  DRIVE,  or  the 
VOLUME_IDENTIFIER  does  not  match  the  volume  identifier  in  the  volume 
header  label  on  the  tape,  or  If  the  tape  is  unlabeled. 

MODE_ ERROR 

is  raised  if  the  file  Identified  by  TAPE _  DRIVE  Is  of  mode  IN  _  FILE. 

STATUS _ ERROR 

is  raised  if  TAPE_ DRIVE  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Notes: 

When  the  first  file  is  written  on  the  tape,  the  file  header  label  will  follow  the  volume  header 
created  by  this  procedure. 

5.3.O.7.  Unloading  a  tape 

procedure  unload  (tape_drive  :  in  file_type)  ; 


Purpose: 

This  procedure  unloads  the  tape  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE_DRIVE.  It  rewinds  the  tape  to  the  beginning  of  tape  and  releases  the  established  block 
size.  Following  completion  of  this  procedure,  the  function  IS_LOADED(TAPH_DRIVE)  will 
return  FALSE. 

Parameters: 

TAPE_DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 


170 


Page  3-253 


PROPOSED  MII/-STD-CA1S 
31  JANUARY  I98S 

Exceptions: 

STATUS _ ERROR 

is  raised  if  TAPE_DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


Notes: 

If  no  conditions  for  these  exceptions  exist  and  there  is  no  tape  loaded  on  the  tape  drive,  this 
procedure  has  no  effect. 

5.3.O.8.  Dismounting  a  tape 

procedure  dismount  (tape_drive  :  in  filejtype); 

Purpose: 

This  procedure  generates  an  implementation-defined  request  that  the  tape  on  the  tape  drive 
represented  by  the  file  identified  by  TAPE_ DRIVE  be  removed  from  the  drive.  It  makes  the 
tape  available  for  removal  and  releases  the  established  density.  Following  the  completion  of  this 
procedure,  the  function  IS_MOUNTED  (TAPE_DIUVE)  will  return  FALSE. 

Parameters: 

TAPE  _  DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

Exceptions: 

USE_ERROR  is  raised  if  MAG NETIC _ TAPE  Is  not  the  value  of  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_ DRIVE. 

STATUS _ ERROR 

Is  raised  if  TAPE _  DRIVE  is  not  an  open  nie  handle. 

DEVICE  _  ERROR 

Is  raised  If  this  operation  cannot  be  completed  because  of  a  malfunction  of  the 
underlying  system. 


Notes: 

If  no  conditions  for  these  exceptions  exist  and  there  Is  no  tape  mounted  on  the  tape  drl.o.  this 
procedure  has  no  effect. 

5.3.O.O.  Determining  if  the  tape  drive  ia  loaded 

function  IS_L0ADED (TAPE  JJRIVE :  In  FILEJTYPE) 
return  BOOLEAN; 


Purpose: 

This  function  returns  TRUE  If  the  tape  on  the  tape  drive  represented  by  the  file  Identified  by 
TAPE  DRIVE  has  been  loaded;  otherwise  It  returns  FALSE. 
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Parameters: 

TAPE  DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 


Exceptions: 

USE  ERROR  is  raised  If  MAGNETIC _ TAPE  is  not  the  value  of  the  attribute  FILE_KIND  or 
the  node  associated  with  the  file  Identified  by  TAPE_ DRIVE. 

STATUS _ ERROR 

Is  raised  If  TAPE_ DRIVE  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


5.3.9.10.  Determining  if  a  tape  is  mounted 

function  ISMOUHTED  (TAP  ED  RIVE  in  FILE_TYPE> 

return  boolean? 


Purpose: 

This  function  returns  TRUE  if  a  tape  is  mounted  on  the  tape  drive  represented  by  the  file 
Identified  by  TAPE _ DRIVE;  otherwise  it  returns  PAUSE. 

Parameters: 

TAPE_  DRIVE  is  an  open  file  handle  on  the  rile  representing  the  tape  drive. 

Exceptions: 

USE_ERROR  Is  raised  ir  MAGNETIC _ TAPE  Is  not  the  value  of  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_  DRIVE. 

STATUS _ ERROR 

is  raised  if  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

5.3.9.11.  Determining  the  poaition  of  the  tape 

function  tape_status  (tape_drive  :  in  file  type) 
return  tape  position; 


Purpose: 

This  function  returns  current  tape  position  Information. 

Parameters: 

TAPE_ DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 
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Rxceptlons: 

USE_ERROR  is  raised  if  MAG NETIC_ TAPE  is  not  the  value  of  the  attribute  FILE _ KIND  of 
the  node  associated  with  the  file  identified  by  TAPE _ DRIVE. 

STATUS _ ERROR 

Is  raised  if  TAPE  _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

5.3.0.12.  Rewinding  the  tape 

procedure  rewindjtape  (tape_drive  :  in  filejtype)  ; 


Purpose: 

This  procedure  positions  the  tape  at  the  beginning  of  tape. 

Parameters: 

TAPE _ DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 


Exceptions: 

USE _ ERROR  is  raised  if  MAGNETIC_TAPE  is  not  the  value  of  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_DRIVE. 

STATUS _ ERROR 

is  raised  If  TAPE  _  DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

5.3.0.13.  Skipping  tape  marks 

procedure  skip_tape_marks(TAPE_drive:  in  file_type: 

NUMBER:  in  INTEGER : =1 ; 

TAPE  STATE:  out  TAPE  POSITION) ; 


Purpose: 

This  procedure  provides  a  method  of  skipping  over  tape  marks.  A  positive  NUMBER  Indicates 
forward  skipping,  while  a  negative  NUMBER  Indicates  backward  skipping.  If  NUMBER  Is  zero, 
the  tape  position  does  not  change. 

Following  a  call  to  SKIP  _ TAPE _  MARKS,  if  NUMBER  is  positive,  the  tape  Is  positioned 
Immediately  following  the  appropriate  tape  mark.  Following  a  call  to  SKIP_TAPE_MARKS, 
if  NUMBER  is  negative,  the  tape  is  positioned  immediately  preceding  the  appropriate  tape  mark 
(l.e.,  at  the  end  of  a  file  or  label).  If  two  consecutive  tape  marks  are  encountered,  the  tape  Is 
positioned  Immediately  following  the  second  one,  even  If  fewer  than  NUMBER  tape  marks  have 
been  skipped.  Additionally,  the  current  column,  current  line  and  current  page  numbers  (see 
[LRMj  14.3)  are  set  to  one. 
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Parameters: 

TAPE_DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

NUMBER  is  the  number  of  taj  marks  to  skip  and  the  direction  of  movement. 

TAPE _ STATE 

is  the  position  of  the  tape  after  skipping  the  specified  number  of  tape  marks. 


Exceptions: 

USE_ERROR  Is  raised  If  MAGNETIC _ TAPE  Is  not  the  value  of  the  attribute  FILE  KIND  or 
the  node  associated  with  the  file  identified  by  TAPE_ DRIVE. 

STATUS _ ERROR 

Is  raised  If  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  If  an  input  or  output  operation  cannot  be  completed  because  of  a 


malfunction  of  the  underlying  system. 

Writing  a  tape  mark 

procedure  writetape  mark  (tapedrive  :  in 

FILE  TYPE: 

NUMBER:  in 

POSITIVE  :=  1; 

TAPESTATE : 

OUt  TAPE_POSITION) 

Purpose: 

This  procedure  writes  NUMBER  consecutive  tape  marks  on  the  tape  which  Is  mounted  on  the 
tape  drive  represented  by  the  file  identified  by  TAPE _ DRIVE.  The  tape  is  stopped  following 
the  last  tape  mark  written. 

Parameters: 

TAPE_DRIVE  Is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

NUMBER  Is  the  number  of  consecutive  tape  marks  to  be  written. 

TAPE  _  STATE 

is  the  new  position  of  the  tape. 


Exceptions: 

USE _ ERROR  Is  raised  if  MAGNETIC _ TAPE  Is  not  the  value  of  the  attribute  FILE  KIND  or 
the  node  associated  with  the  file  Identified  by  TAPE_DllfVK  or  if 
IS_LOADI'.D(TAPE_ DRIVE)  Is  FALSE. 

MODEERROR 

is  raised  if  the  file  Identified  by  TAPK_DRIVE  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  If  TAPE  DRIVE  is  not  an  open  file  handle. 
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DEVICE  _  ERROR 

Is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 


5.3.0.15.  Writing  a.  volume  header  label 


procedure  voluve_header (tape_drive : 

VOLUME_IDENTIFIER : 
ACCESSIBILITY: 


in  FILE_TYPE; 
in  V0LUME_STRING ; 
in  CHARACTER  :='  •) ; 


Purpose: 

This  procedure  writes  a  volume  header  label,  as  described  In  TABLE  XI  on  the  tape  loaded  on 
the  tape  drive  represented  by  the  file  identified  by  TAPE_DRIVE. 


The  accessibility  character  Is  obtained  from  the  ACCESSIBILITY  parameter.  The  owner 
identification  is  the  user  name  indicated  by  ’CURRENT_USER.  The  Label-Standard  Version, 
which  is  3,  indicates  the  ANSI  standard  version  to  which  these  labels  conform. 


Table  XI.  Volume  header  label 

Character 

Position 

Field  Maae 

Content 

1  to  3 

1 

Label  Identifier 

1  VOL 

4 

1 

Label  Nuaber 

1  1 

6  to  10 

1 

Volnae  Identifier 

1  Assigned  peraanently 

1 

1  by  owner  to  identify 

1 

1  voluae 

11 

1 

Accessibility 

1  Indicates  restrictions 

1 

1  on  access  to  the 

1 

1  information  on  the 

1 

1  voluae 

12  to  37 

1 

Reserved  for  Future 

1  Spaces 

1 

Standardization 

1 

38  to  51 

1 

Owner  Identity 

1  Identifies  owner  of 

1 

1  voluae 

52  to  79 

1 

Reserved  for  Future 

1  Spaces 

1 

Standardization 

i 

1 

80 

I 

Label-Standard 

1  Indicates  the  version 

1 

Version 

1  of  the  ANSI  standard 

1 

1  to  which  the  labels 

1 

1  and  data  foraats  on  this 

1 

1  voluae  confora 

Parameters: 


TAPE_ DRIVE  is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

VOLUME_  IDENTIFIER 

is  a  six-character  string  giving  the  volume  name. 
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ACCESSIBILITY 

Is  a  character  representing  restrictions  on  access  to  the  tape,  in  accordance  with 
[ANSI  78];  a  SPACE  indicates  no  access  control. 


Exceptions: 

USE_ERROR  Is  raised  If  MAGNETIC_TAPE  is  not  the  value  of  the  attribute  FILE  KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_DRIVE.  USE  ERROR  is 
also  raised  If  the  tape  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE  _  DRIVE  was  loaded  ns  01  unlabeled  tape  or  if  the  value  of 
VOLUME _  IDENTIFIER  does  not  conform  to  the  syntax  of  an  Ada  identifier. 
USE_  ERROR  is  also  raised  If  IS _LOADED( TAPE _  DRIVE)  Is  FALSE  at  the  time 
of  the  call. 

MODE_ ERROR 

Is  raised  If  the  file  identified  by  TAPE_ DRIVE  is  of  mode  IN_FILE. 

STATUS _ ERROR 

is  raised  if  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEVICE_  ERROR 

Is  raised  if  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

5.3.9.16.  Writing  a  file  header  label 

procedure  F I leheader (tape  dr tve  :  in  file  _type; 

FILE~  fbEHTIFIER :  in  FILE  STRIMC ; 

EXPIRATION_DATE :  in  STRING  :=*  99368"; 

ACCESSIBILITY  :  in  CHARACTER  :='  *) ; 


Purpose: 

This  procedure  writes  a  file  header  label,  as  described  In  TABLE  XII',  on  the  tape  loaded  on  the 
tape  drive  represented  by  the  rile  Identified  by  TAPE _  DRIVE. 

Parameters: 
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Table  XII.  File  header  label 

Character 

Position 

Field  Naae 

Content 

1  to  3 

1 

Label  Identifier 

1  HDR 

4 

1 

Label  Nuaber 

1 

|  1 

S  to  21 

File  Identifier 

1  Assigned  peraanently  by 

1 

1 

1  systea  to  Identify  file 

1 

23  TO  27 

1 

File  Set  Identifier 

1  The  VOLUME  IDENTIFIER 

1 

| 

1  in  the  file  set 

28  to  31 

1 

1 

1 

File  Section  Nnaber 

1  0001 

1 

1 

32  to  38 

1 

1 

1 

File  Sequence  Nuaber 

1 

I 

1  Distinguishes  files  in  a 

1 

1  file  set.  First  file  in 

1 

1  set  gets  *0001*.  For 

1 

1  each  file  after. 

1 

1  sequence  nuaber  Is 

1 

1  lncreaented  by  one  base  10. 

38  to  38 

1 

Generation  Nuaber 

I  0001 

40  to  41 

l 

Generation  Version 

1 

1  00 

1 

1 

Nuaber 

1 

42  to  47 

1 

Creation  Date 

i 

1  Data  file  header  Is 

1 

1  written 

48  to  S3 

1 

Expiration  Date 

1  Date  on  which  flit  any  bt 

1 

1  overwritten 

64 

1 

Accessibility 

1  Indicate*  restriction*  on 

1 

1  access  to  lnforastlon  m 

1 

1  file 

66  to  60 

1 

Block  COUNT 

1  000000 

61  to  73 

I 

| 

Systea  Code 

1  Space* 

i 

74  to  80 

1 

Reserved  for  Future 

1  Spaces 

1 

Standardization 

1 

Parameters: 


TAPE  _  DRIVE  Is  an  open  (lie  handle  on  the  file  representing  the  tape  drive. 

FIl.E_  IDENTIFIER 

Is  a  17-character  string  giving  the  file  name. 

EXPIRATION  _  DATE 

is  a  string  identifying  the  date  (6  characters  '  YYDDD’  where  YY  Is  the  year  and 
DDD  Is  the  day  (001-386))  the  file  may  be  overwritten.  When  the  expiration  date  Is 


Page  3-260 


186 


PROHO'KD  Mll-o-rn-c  \l» 
31  .1  VM  \R1 


a  space  followed  by  5  rerocs,  the  Hie  has  expired.  ACCESSIBILITY 

Is  a  character  representing  restrictions  on  access  to  the  tape,  In  accordance  with 

(ANSI  78];  a  SPACE  Indicates  no  access  control. 


Exceptions: 

USE_ERROR  is  raised  if  MAGNETIC_TAPE  is  not  the  value  of  the  attribute  FILE  KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_  DRIVE.  USE_  ERROR  is 
also  raised  if  the  tape  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE_DRIVE  was  loaded  as  an  unlabeled  tape  or  if  FILE_ IDENTIFIER  does  not 
conform  to  the  syntax  of  an  Ada  identifier.  USE_ ERROR  is  also  raised  if 
IS_LOADED(TAPE  DRIVE)  is  FALSE  at  the  time  of  the  call. 


MODE _ ERROR 

is  raised  if  the  file  identified  by  TAPE _ DRIVE  Is  of  mode  IN _ FILE. 

STATUS _ ERROR 

is  raised  if  TAPE _  DRIVE  is  not  an  open  file  handle. 

DEV1CE_  ERROR 

is  raised  if  an  input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system. 

5.3.9.17.  Writing  an  end  of  file  label 

procedure  EKD_FILE_UBEL(TAI>E_DRXVE:  in  FILETYPE) ; 


Purpose: 

This  procedure  writes  an  end  of  rile  label,  as  shown  in  TABLE  XHI  on  the  tape  loaded  on  the 
tape  drive  represented  by  the  file  Identified  by  TAPE  DRIVE. 


Table  Xili.  End  of  file  label 


Character 


Position 

Field  Naan 

Contents 

1  to  3 

1 

Label  Identifier 

1 

EOF 

4 

1 

1 

Label  Nuaber 

1 

1 

5  to  64 

1 

1 

Saae  aa  corresponding 
fields  in  file  header 

1 

1 

Saae  a a  corresponding 
fields  in  file  header 

1 

1 

label 

1 

label 

56  to  60 

1 

j 

Block  COUNT 

! 

Nuaber  of  blocks  in  file 

61  to  80 

1 

1 

Saae  aa  corresponding 
fields  in  file  header 

i 

t 

Saae  as  corresponding 
fields  In  file  header 

1 

label 

t 

label 

Parameters: 

TAPE  _ DRIVE  is  an  open  file  handle  on  the  file  representing  the  tape  drive. 
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Exceptions: 

USB _ ERROR  Is  raised  If  MAG NETIC_ TAPE  Is  not  the  value  of  the  attribute  FILE_KIND  of 
the  node  associated  with  the  file  identified  by  TAPE_DRfVE.  USE_ ERROR  Is 
also  raised  If  lS_LOADED(TAPE_DRIVE)  Is  FALSE  at  the  time  of  call  or  if  the 
tape  on  the  tape  drive  represented  by  the  file  Identified  by  TAPE_DRfVE  was 
loaded  as  an  un  labeled  tape. 

MODE_ ERROR 

Is  raised  if  the  file  Identified  by  TAPE_  DRIVE  Is  of  mode  1N_FILE. 

STATUS _ ERROR 

Is  raised  If  TAPE_DRIVE  is  not  an  open  file  handle. 

DEVICE  _  ERROR 

is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  syste  m. 

5.3.0.18.  Reading  a  label  on  a  labeled  tape 

procedure  readlabel  ctapedrive  :  in  file_type; 

LABEL:  OUt  LABELSTRING)  ; 

Purpose: 

This  procedure  obtains  th  first  80  characters  of  the  next  available  block  and  returns  them  In 
LABEL. 

Parameters: 

TAPE_ DRIVE  is  an  open  file  handle  on  the  file  representing  the  tape  drive. 

LABEL  is  the  80-character  string  read  from  the  tape. 


Exceptions: 

USE _  ERROR  Is  raised  If  the  attempt  to  read  eighty  characters  encounters  a  tape  mark  or  if 
MAGNETIC_TAPE  is  not  the  value  of  the  attribute  FILE_KIND  of  the  node 

associated  with  the  file  Identified  by  TAPE_DRIVE  or  if 

IS  _LOADED(TAPE_  DRIVE)  Is  FALSE  at  the  time  of  the  call.  USE_ ERROR  Is 
also  raised  if  the  tape  on  the  tape  drive  represented  by  the  file  identified  by 
TAPE_ DRIVE  was  loaded  as  an  unlabcled  tape. 

STATUS _ ERROR 

Is  raised  If  TAPE _  DRIVE  Is  not  an  open  file  handle. 

DEVICE  _  ERROR 

Is  raised  If  an  Input  or  output  operation  cannot  be  completed  because  of  a 
malfunction  of  the  underlying  system  or  if  the  tape  is  uninitialized. 
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5.3.10.  Package  FILE_IMPORT—  EXPORT 

The  CAIS  allows  a  particular  CAJS  implementation  to  maintain  files  separately  from  files  maintained 
by  the  host  file  system.  This  package  provides  the  capability  to  transfer  files  between  these  two 
systems. 


5.3.10.1.  Importing  a  file 

procedure  import  (node:  in  nodetype; 

HOST_FILE_NAKE :  in  STRING); 

Purpose: 

This  procedure  searches  for  a  file  in  the  host  file  system  named  HOST_FILE_NAME  and 
copies  its  contents  into  a  CAJS  file  which  is  the  contents  of  the  node  Identified  by  NODE.  It  also 
copies  any  file  characteristic  Information  which  must  be  maintained  by  the  CAIS 
implementation. 

Parameters: 

NODE  is  an  open  node  handle  on  the  file  node. 

HOST  _  FILE  _  NAME 

is  the  name  of  the  host  file  to  be  copied. 


Exceptions: 

NAME  _  ERROR 

is  raised  if  the  node  identified  by  NODE  Is  inaccessible. 

USE_ ERROR  Is  raised  if  HOST_ FILE _  NAME  does  not  adhere  to  the  required  syntax  Tor  file 
names  in  the  host  file  system  or  if  HOST _ FILE _ NAME  does  not  exist  in  the  host 
file  system.  USE_ERROR  Is  also  raised  if  FILE  Is  not  the  value  or  the  attribute 
KIND  of  the  node  identified  by  NODE. 

STATUS _ ERROR 

is  raised  If  NODE  is  not  an  open  node  handle. 

INTENT  _  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  intent  establishing  the  right  to  write 
contents. 

SECURITY_  VIOLATION 

Is  raised  If  the  operation  represents  a  violation  of  mandatory  access  controls. 
SECURITY  _ VIOLATION  Is  raised  only  If  the  conditions  for  other  exceptions  are 
not  present. 


Additional  Interface: 

procedure  import  (name:  in  namestring; 

HOSTFILENAME :  in  STRING) 

is 

NODE : N0DE_TYPE ; 
begin 

OPEN (NODE, NAME, (1=>WRITE  CONTENTS)); 
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IMPORT (NODE, HOST_FILE_NAME)  ; 
CLOSE  (NODE); 
exception 

when  others  => 

CLOSE (MODE) ; 
raise; 

end  IMPORT; 


5.3.10.2.  Exporting  a  file 

procedure  export  (NODE:  in  node_type: 

HOST  FILE  NAME:  in  STRING); 


Purpose: 

Vhis  procedure  creates  a  new  file  named  HOST  _  FILE _  NAME  In  the  host  file  system  and 
copies  the  contents  of  the  file  node  Identified  by  NODE  Into  It. 


Parameters: 

NODE  is  an  open  node  handle  on  the  file  node. 

HOST  _  FILE  _  NAME 

Is  the  name  of  the  host  file  to  be  created. 


Exceptions: 

NAME  _  ERROR 

Is  raised  If  the  node  identified  by  NODE  Is  inaccessible. 

USE_  ERROR  Is  raised  If  HOST_ FILE _ NAME  does  not  adhere  to  the  required  syntax  for  file 
names  in  the  host  file  system  or  If  HOST _ FILE _  NAME  cannot  be  created  in  the 
host  file  system.  USE _  ERROR  is  also  raised  If  FILE  Is  not  the  value  of  the 
attribute  KIND  of  the  node  Identified  by  NODE. 

STATUS _ ERROR 

Is  raised  If  NODE  Is  not  an  open  node  handle. 

INTENT_  VIOLATION 

is  raised  if  NODE  was  not  opened  with  an  Intent  establishing  the  right  to  read 
contents. 


Additional  Interface: 

procedure  export  (name:  in  name_string; 

HOST_F I LE_NAME :  in  STRING) ; 

ia 

NODE : NODE_TYPE ; 
begin 

OPEN (NODE, NAME. (I=>READ_CONTENTS) ) ; 

EXPORT (NODE. HOST_FILE_NAME) ; 

CLOSE  (NODE); 
exception 

when  others  => 

CLOSE  (NODE) ; 
raise; 
end  EXPORT; 
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5.4.  CA1S  Utilities 

This  section  defines  the  abstract  data  type  LIST_TYPE  for  use  by  other  CAJS  interfaces.  The  value 
of  an  entity  of  type  LIST_TYPE  (referred  to  as  a  list)  is  a  linearly  ordered  set  of  data  elements 
called  list  items. 

It  Is  possible  to  associate  a  name  with  a  list  item.  If  no  name  Is  associated  with  a  list  Item,  the  item  is 
an  unnamed  item.  If  a  name  is  associated  with  a  list  item,  the  item  is  a  named  item.  A  list  can 
either  contain  all  unnamed  items,  in  which  case  it  is  called  an  unnamed  list,  or  all  named  items,  In 
which  case  it  Is  called  a  named  list,  but  not  both.  If  a  list  contains  all  named  items,  names  among 
these  items  must  be  unique.  An  empty  list  is  a  list  which  contains  no  items.  Such  a  list  is  not 
considered  to  be  either  named  or  unnamed.  An  empty  list  can  be  obtained  by  using  the 
EMPTY_LIST  constant  or  the  DELETE  procedure.  The  type  LIST_KIND  enumerates  these  three 
c'assifications  of  lists. 

Associated  with  each  list  item  Is  a  classification,  or  kind.  List  Items  are  classified  as  strings,  integers, 
float  numbers,  identifiers  and  lists.  The  kind  of  an  Item  Is  a  value  of  the  enumeration  type 
ITEM_KIND.  The  CAJS  interfaces  allow,  but  do  not  require,  an  Individual  implementation  of  the 
CAJS  to  employ  efficient  mechanisms  for  representing  identifiers  as  part  of  lists.  Towards  this 
purpose,  a  private  type  TOKEN _ TYPE  Is  introduced,  which  allows  identifiers  to  be  manipulated  as 
internal  representations  called  tokens.  Interfaces  are  provided  to  transform  identifiers  in  the  form  of 
a  NAME _ STRING  Into  a  TOKEN _ TYPE  and  vice  versa.  NAME  STRING  Is  a  subtype  of 
STRING,  whose  values  are  assumed  to  conform  to  the  syntax  of  Ada  Identifiers.  Tokens  are  equal  if 
and  only  if  their  external  representations  are  equal  under  string  comparison,  excepting  differences  in 
upper  and  lower  case  notation. 

The  names  or  list  Items  in  a  named  list  may  be  internally  represented  as  tokens.  Overloaded  interfaces 
are  provided  In  the  CAJS  that  allow  the  names  of  list  items  within  a  named  list  to  be  specified  by 
parameters  of  either  NAME _ STRING  or  TOKEN_TYPE  type. 

The  specifications  within  this  package  allow  for  the  manipulation  of  lists  which  are  of  unnamed, 
named  or  empty  kind.  If  a  parameter  of  an  interface  specifies  an  Item  by  position,  then  that  Interface 
may  be  used  with  either  unnamed  lists  or  named  lists.  If,  however,  a  parameter  specifies  an  item  by 
name,  then  the  associated  Interface  may  only  be  used  with  named  lists. 

Items  of  a  list  can  be  manipulated  by: 

a.  extracting  items  from  a  list, 

b.  replacing  or  changing  values  of  items  in  a  list,  and 

c.  inserting  new  items  Into  a  list. 

These  operations  are  provided  by  the  EXTRACT,  REPLACE,  and  INSERT  subprograms, 
respectively.  Packages  are  provided  to  allow  such  operations  to  be  performed  dlreetly  on  strings, 
identifiers  and  lists.  Operations  on  the  numeric  types  are  provided  with  generic  packages. 

The  positions  in  the  list  where  these  operations  are  specif  d  to  lake  place  are  usually  designated  by 
the  parameter  POSITION.  With  named  lists  a  particular  item  can  bo  specified  by  a  name.  This  Is 
possible  since  such  names  by  definition  arc  unique.  Specifying  a  particular  Item  by  name  is  only 
permitted  with  EXTRACT  and  REPLACE  operations. 

Insertion  operations  can  also  be  performed  on  sets  of  items.  A  set  would  then  effectively  constitute  a 
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(sub)llst.  Operations  to  delete  an  item  or  a  set  of  Items  are  also  provided.  Insertion  and  deletion 
operations  will  adjust  the  ordinal  positions  of  items  after  the  inserted  or  deleted  items. 

The  value  of  an  entity  of  type  LIST_TYPE  can  be  represented  externally  to  the  package 
LIST  _  UTILITIES  as  a  string.  Interfaces  are  provided  to  convert  between  entitles  of  type  STRING, 
containing  a  string  value  consistent  with  the  syntax  of  this  external  representation,  and  entities  of 
type  LIST _  TYPE.  An  object  of  type  LIST _  TYPE  has  as  Its  Initial  value  the  empty  list.  The  BNF 
for  a  list's  external  representation  Is  given  in  TABLE  XIV. 


Table  XIV.  List  external  representation  BNF 


list  nsaad_llst 

I  unnsatd_llst 

I  •»pty_ll»t 

nsatd_llst  ::=  (naa«d_ltea  <  .  nsa*d_lt«*  >  ) 

unn*a*d_llst  ::=  (ltta  {  .  lt«a  >  ) 

•apty_ll«t  ::=  0 

n*a«d_ltea  ::  =  naa«_strlng  =>  ltam 
ltea  : :=  list 

I  quot«d_strlng 
I  lnt«gtr_numbsr 
I  f lost_nuaber 
I  ldantlflsr 

lnt«g*r_numb*r  ::=  lntagsr 
flost_nusb«r  ::=  d«clmsl_llt«ral 
quotsdstring  ::=  strlnglltsral 
nsmsstrlng  identifier 


Notstlon: 

1 .  Words  -  syntactic  categories 

2.  [  ]  -  optional  ltess 

3.  {  >  -  an  ltea  repeated  zero  or  times 

4.  I  -  separates  alternatives 


The  CAJS  defines  a  canonical  external  string  repres<  "nation  for  values  of  type  LIST_TYPE.  The 
string  subtype  LIST_TEXT  is  used  In  the  OAIS  Interfaces  for  string  values  that  adhere  to  this 
canonical  external  representation.  This  external  representation  Is  obtained  by  applying  the 
TO_TEXT  operation  to  a.  value  of  type  LIST__TYI'E  or  to  a  value  that  Is  a  legal  value  of  a  list 
Item. 

The  canonical  external  string  representation  of  a  value  of  type  LIST _ TYPE  and  of  Its  list  Items  Is 
defined  as  follows: 

a.  For  an  Integer  list  item,  the  external  si  riot,  rope  -sen  tat  Inn  Is  the  decimal  representation  of 
its  numeric  value  without  leading  zeroes. 

b.  For  a  floating  point  list  Item,  the  externa1  siring  representation  Is  the  string  Image  of  Its 
numeric  value  In  decimal  notation  with  a  format  as  obtained  under  Implementation-denned 
settings  of  the  FORK,  AFT.  and  EXP  parameters  In  PUT  operations  of  Ada  TKXT_IO 
(sec  jLRMj  M  ILS).  These  settings  of  FORK.  AFT,  and  EXP  must  guarantee  that  quality 
of  the  external  representation  Implies  equality  of  the  Internal  representation  and  vlee  versa 
within  the  limitations  imposed  by  the  accuracy  of  numeric  comparisons  in  Ada. 
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c.  For  an  Identifier  list  Item  or  the  name  of  a  list  Item,  the  external  string  representation  is 
the  Identifier  string  in  upper  case  characters. 

d.  For  a  quoted  string  list  item,  the  external  string  representation  Is  the  string  literal 
representing  the  value  of  the  list  item  (i.e.,  the  string  value  enclosed  by  quotation 
characters  and  with  inner  quotation  characters  doubled). 

e.  for  a  list  as  a  list  item,  the  external  string  representation  is  the  external  representation  of 
the  value  of  the  list. 

f.  for  a  list,  the  external  string  representation  of  its  value  is  the  string  representation 
composed  of  the  external  representation  of  Its  list  Items  according  to  the  syntax  of  Table 
XVII  without  blanks,  format  effectors  or  non-printing  characters  between  the  lexical  or 
syntactic  constituents  of  the  syntax. 


5.4.1.  Package  LIST_UTILITIES 

This  package  defines  types,  subtypes,  constants,  exceptions  and  general  list  manipulation  interfaces. 
The  latter  are  supplemented  by  generic  sitbpaekages  Tor  the  manipulation  of  list  items  of  numeric 
type. 


5. 4. 1.1.  Types  and  aubtypea 


type  LISTTYPE 
type  TOKEN  TYPE 
type  LISTKIND 
type  ITEMKIND 

subtype  list  text 
aubtype  have  string 
type  count 


is  limited  private; 

is  limited  private; 

is  (UNSAVED,  NAVED.  EMPTY); 

is  (LIST  ITEM.  STRING  ITEM.  INTEGERITEM . 

FLOAT_ITEM.  IDENITFIER  ITEM)  ; 
is  STRING; 
is  STRING; 

is  range  o  . .  integer -last; 


subtype  position  count  is  count  range  count -first 


♦  l 


COUNT-LAST; 


LIST  _  TYPE  describes  the  type  for  lists.  TOKEN_TYPE  describes  the  type  Tor  internal 
representations  or  Identifiers.  LIST _ KIND  enumerates  the  kinds  or  lists.  ITEM _ KIND  enumerates 
the  kinds  of  list  Items.  LIST _ TEXT  Is  the  type  or  a  list's  external  representation.  ITEM  TEXT  is 
the  type  of  a  list  item  s  external  representation  NAME_ STRING  Is  the  type  or  an  identifier  or  of  an 
Item's  name  in  a  named  Item  In  Its  external  representation.  COUNT  describes  the  type  for  the  length 
of  a  list.  POS IT ION_ COUNT  describes  the  type  for  the  position  of  an  Item  in  a  non-empty  list. 


EMPTY _  LIST  :  constant  LIST  TYPE; 


EMPTY_ LIST  Is  a  deferred  constant  denoting  the  value  of  an  empty  list.  Any  implementation  of 
the  CAIS  must  ensure  that  IS _ EQUAL! EMPTY _ LIST,  X)  Is  TRUE  Tor  any  object  X  or  type 
LIST_TYPK  whose  value  is  an  empty  list. 

SEAKOI I  _  ERROR  :  exception; 


CONSTRAINT_ERROR:  exception; 


SEAR(  ll_ERKOR  is  raised  if  a  search  for  an  item  fails  because  the  item  Is  not  present  in  (he  IM 
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CONSTRAINT_ERROR  is  raised  if  an  attempt  is  made  to  convert  a  value  to  a  numeric  type  when 
the  value  does  not  satisfy  the  constraints  for  that  type. 


5.4. 1.2.  Copying  a  list 


procedure  copy(to_list: 

FROM  LIST: 


OUt  LIST  TYPE; 
in  LIST  TYPE)  ; 


Purpose; 

This  procedure  returns  In  the  parameter  TO _ LIST  a  copy  of  the  list  value  of  the  parameter 
FROM _ 1. 1ST.  Subsequent  modifications  of  either  list  do  not  affect  the  other  list. 

Parameters: 

TO  _  LIST  is  the  list  returned  as  a  copy  of  the  value  of  FROM  _  LIST. 

FROM  LIST  is  the  list  to  be  copied. 


Exceptions: 

None. 


5. 4. 1.3.  Converting  to  an  internal  liat  representation 

procedure  to_list(list_strihg:  in  STRING:) 

LIST:  OUt  LIST_TYPE)  ; 

Purpose: 

This  procedure  converts  the  string  representation  of  a  list  into  the  Internal  list  representation. 
It  establishes  the  list  as  a  named,  unnamed,  or  empty  list.  The  Individual  list  items  are  classified 
according  to  their  external  representation.  For  a  numeric  Item  value,  the  item  is  classified  as  an 
integer  Item  if  the  numeric  value  can  be  interpreted  as  a  literal  of  universal  _ integer  type; 
otherwise,  the  numeric  Hein  is  classified  as  a  floating  point  Item.  Blanks,  format  effectors  and 
non-printing  characters  arc  allowed  in  the  value  of  the  parameter  LIST_STRING. 

Parameters: 

LIST  _STRING 

is  the  string  to  be  Interpreted  as  a  list  value. 

LIST  Is  the  list  built  and  returned  according  to  the  contents  of  LIST  STRING. 


Exceptions: 

USE _  ERROR  Is  raised  If  the  value  of  the  parameter  LIST  _ STRING  does  not  conform  to  the 
syntax  of  TABLE  XIV,  Blanks,  format  effectors  and  non-piinling  characters  are 
allowed  between  lexical  or  syntactic  elements  of  this  syntax. 

CONSTRAINT  _  ERROR 

is  raised  if  a  numeric  literal  In  the  LIST _ STRING  parameter  designates  a  value 
which  cannot,  be  represented  as  the  value  of  an  Item  In  the  LIST  result. 
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5.4. 1.4.  Converting  to  an  external  list  representation 

function  to  text  (list_itek.  in  list  type) 
return  list  text; 


Purpose: 

This  function  returns  the  external  representation  of  the  value  of  the  LIST_ ITEM  parameter. 
The  representation  is  the  string  representation  defined  In  Section  5.4. 

Parameters: 

LIST  ITEM  is  the  list  to  be  converted. 


Exceptions: 

None. 


5.4.I.5.  Determining  the  equality  of  two  lists 

function  IS_EQUAL(LIST1 :  in  list_type; 

LISTS:  in  LISTTYPE) 
return  boolean; 

Purpose: 

This  function  returns  TRUK  if  the  values  of  the  two  li  is  LISTl  and  LIST2  are  equal  according 
to  the  following  rules;  otherwise,  it  returns  FALSE. 

Two  values  of  type  LIST _ TYPE  are  equal  if  and  only  if; 

a.  both  lists  are  of  the  same  kind  (i.e.,  named,  unnamed  or  empty),  and 

b.  both  lists  contain  the  same  number  of  list  Items,  and 

c.  for  each  position,  the  values  of  list  items  at  this  position,  as  obtained  by  an  EXTRACT 
operation,  are  of  the  same  kind  and  are  equal  under  the  equality  defined  for  this  kind, 
and 

d.  in  the  case  of  named  lists,  for  each  position,  the  names  of  the  list  items  at  this  position 
are  equal  under  TOKEN _ TYPE  equality  (i.e.,  IS_KQUAL). 

Parameters: 

LISTl,  LIST2  are  the  lists  whose  equality  Is  to  be  determined. 


Exceptions: 

None. 


5. 4. 1.6.  Deleting  an  item  from  a  list 


procedure  delete  (list:  in  out  list_type; 

POSITION:  in  POSITION  COUNT) ; 

procedure  delete  (list:  in  out  list  type; 

NAKED:  in  NAMESTRING) ; 

procedure  delete  (LIST:  in  out  list  type; 
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MAMED:  in  TOKEN  TYPE) ; 

Purpose: 

This  procedure  deletes  the  item  specified  by  POSITION  or  NAMED  from  LIST.  If  this  was  the 
last  item  in  the  list,  the  kind  of  the  list  changes  to  EMPTY. 

Parameters: 

1, 1ST  is  the  list  from  which  the  item  will  be  deleted. 

POSITION  is  the  position  within  the  list  thai  identifies  the  item  to  be  deleted. 

NAMED  Is  the  name  of  the  list  Item  to  be  deleted. 


Exceptions: 

USE_  ERROR  Is  raised  if  the  parameter  NAMED  is  used  with  an  unnamed  list,  If  the  list  Is  empty, 
if  there  is  no  item  with  the  name  .AMED  or  if  POSITION  has  a  value  larger  than 
the  current  length  of  LIST. 

5.4. 1.7.  Determining  the  kind  of  liat 

function  getlistkind  (list  :  in  list  rrpE) 
return  list  kind; 


Purpose: 

This  function  returns  the  kind  of  the  referenced  I'  t. 
Parameters: 

LIST  is  the  list  of  Interest. 


Exceptions: 

None. 


5. 4. 1.8.  Determining  the  kind  of  list  item 

function  get_item_kimd(LIST:  in  list  type; 

POSITION:  in  FOSITIOM_COUNT) 
return  item_kimd; 

function  get_item_kihd(list:  in  list  rYPE; 

MAMED:  in  NAVI  STRING) 
return  itemkind; 

function  get_item_kind(list:  in  list  type; 

MAMED:  in  TOK  :N  TYPE) 
return  item  kind; 


Purpose; 

This  function  returns  the  kind  of  an  item  in  the  r  fore  need  list. 


Parameters: 


tnfl 


Page  3-270 


PROPOS'D  MII.-sTD-r  \ls 
31  JAM  AR^  Kitts 

LIST  Is  the  list  of  interest. 

POSITION  is  the  position  within  the  list  that  identifies  the  item. 

NAMED  is  the  name  of  the  list  item. 

Kxceplions: 

USE_ ERROR  or  if  POSITION  has  a  value  larger  than  the  current  length  of  LIST  or  if  the  list  is 
empty. 

SEARCH  ERROR 

is  raised  if  there  is  no  item  with  the  name  NAMED. 


5.4. 1.9.  Inserting  a  aublist  of  items  into  a  Hat 


procedure  splice(list:  in  out  list  type; 

POSITION:  in  POSITION_COUNT; 
SUB  LIST:  in  LIST  TEXT); 


procedure  splice  (LIST:  in  out  LIST  TYPE; 

POSITION:  in  POSITION_COUNT; 

SUB_LIST:  in  LIST_TYPi) ; 

Purpose: 

This  procedure  allows  a  list  to  be  Inserted  Into  a  list.  The  Items  in  the  list  to  be  inserted  will 
become  items  in  the  resulting  list.  Subsequent  modifications  to  the  value  of  LIST  or  to  the  value 
of  SUB  LIST  do  not  affect  the  other  list. 


Parameters: 

LIST  is  the  list  into  which  a  list  Is  to  be  inserted. 

POSITION  Is  the  position  after  which  the  new  Items  will  be  inserted. 

SUB  LIST  is  the  list  to  be  inserted. 


Exceptions: 

USE _ ERROR  is  raised  if  SUR_I.IST  as  LIST_TEXT  does  not  conform  to  the  syntax  specified  in 
TABLE  XIV.  USE _  ERROR  Is  also  raised  tr  LIST  and  SUB _  LIST  are  not  of  the 
same  kind  and  neither  of  them  is  an  empty  list.  USE_ERROR  is  also  raised  if  LIST 
and  SUB_LIST  are  both  named  and  contain  an  Item  of  the  same  name  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 


5.4.1.10.  Merging  two  lists 


procedure  merge(front:  in  list  type; 

BACK:  in  LIST  TYPE; 

RESULT:  in  Out  LIST”  TYPE); 


Purpose: 

This  procedure  returns  in  RESULT  n  list  constructed  hy  concatenating  BACK  to  h'RONT.  The 
lists  FRONT  and  BACK  must  he  of  the  same  kind  or  either  FRONT  or  BACK  must  he  an 
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empty  list.  The  values  of  FRONT  and  BACK  are  not  affected.  Subsequent  modifications  to  the 
values  of  FRONT  or  BACK  or  to  the  value  of  tin*  returned  RESULT  list  do  not  affect  the  other 
list. 

Parameters: 

FRONT  is  the  first  list  to  be  merged. 

BACK  is  the  second  list  to  be  merged. 

RESULT  is  the  list  produced  by  the  merge;  It  has  the  list  items  of  FRONT  in  its  initial 

sublist  and  those  of  BACK  as  the  rest  of  its  items. 

Exceptions: 

USE_ ERROR  Is  raised  if  FRONT  and  BACK  are  not  of  the  same  kind  and  neither  of  them  is  an 
empty  list.  USE_ERROR  is  also  raised  If  FRONT  and  BACK  are  both  named  and 
contain  an  item  with  the  same  name. 

5.4.1.11.  Extracting  a  sublist  of  items  from  a  list 

function  set_extract(list:  in  listtype; 

POSITION :  in  POSITIONCOUNT; 

LENGTH :  in  POSITIVE :=  POSITIVE ‘LAST) 

return  list  text; 


Purpose: 

This  function  allows  a  (sub)llst  to  be  extracted  from  a  list.  The  returned  value  is  a  copy  of  the 
list  subset  that  starts  at  the  Item  at  POSITION  and  has  LENGTH  Items  In  It.  If  there  are 
fewer  than  LENGTH  items  in  this  part  of  the  list,  the  subset  extends  to  the  tail  of  the  list. 

Parameters: 

LIST  is  the  list  containing  the  subset  to  be  extracted. 

POSITION  is  the  position  within  the  list  that  Identifies  the  subset  to  be  extracted. 

LENGTH  is  the  length  of  the  subset. 


Exceptions: 

USE_ ERROR  Is  raised  If  POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

5.4.1.12.  Determining  the  length  of  a  list 

function  length  (list:  in  list  typf) 
return  COUNT; 


Purpose: 

This  function  returns  a  count  of  the  nunih-r  of  items  in  LIST.  If  LIST  is  empty.  LENGTH 
returns  zero. 
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Parameters: 


LIST  is  the  list  of  Interest. 


Receptions: 

None. 


5.4.1.13.  Determining  the  length  of  a  string  representing  a  list  or  a  list  item 

function  text_length(list:  in  list  type) 

return  natural; 

function  text_length(list:  in  list  type; 

POSITION:  in  POSITION_COUNT) 

return  positive; 

function  text_length(list:  in  list  type; 

NAMED:  in  NAME_STRING) 
return  positive; 

function  text_length (list :  in  list  type: 

NAMED:  in  TOkiNTYPE) 

return  positive; 


Purpose: 

This  function  returns  the  length  of  a  string  representing  either  a  list  or  the  list  item  identified 
by  POSITION  or  NAMED  in  a  list. 

Parameters: 

LIST  is  the  list  of  Interest. 

POSITION  is  the  position  within  the  list  that  identifies  the  item. 

NAMED  is  the  name  of  the  list  item. 


Exceptions: 

USE_ ERROR  is  raised  if  POSITION  has  a  value  larger  than  the  (existing)  length  of  the  list  or  if 
the  parameter  NAMED  is  used  with  an  unnamed  list. 

SEARCH _ ERROR 

is  raised  if  there  is  no  item  with  the  name  NAMED. 


5.4.1.14.  Determining  the  name  of  a  named  item 

procedure  itemname (list :  in  list  type; 

POSITION:  in  P0SITIQN_C0UNT ; 
NAME  :  OUt  TOKEN  TYPE)  ; 


Purpose: 

This  function  returns  in  NAME  the  token  representation  of  the  name  of  the  item  in  the  named 
list,  as  .specified  by  POSITION. 
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Parameters: 

LIST  is  the  list  of  interest. 

POSITION  is  the  position  within  the  list  that  Identifies  the  item. 

NAME  is  the  token  representation  of  the  name  of  the  item  in  the  named  list. 

Exceptions: 

USE _  ERROR  Is  raised  if  LIST  Is  not  a  named  list.  If  POSITION  has  a  value  larger  than  the 
current  length  of  LIST. 

5.4.1.15.  Determining  the  position  of  a  named  item 

function  pos ition_by_name (list;  in  listjtype ; 

MAMED:  in  NAMi_STRING) 

return  position_count; 

function  positionby  name  (list  .  in  listjtype; 

MAMED;  in  TOKEN JTYPE) 
return  positiom  coumt: 

Purpose: 

This  function  returns  the  position  at  which  an  item  with  the  given  name  NAMED  Is  located  in 
LIST.  It  may  only  be  used  with  named  lists. 

Parameters: 

LIST  Is  the  list  In  which  the  position  of  an  Item  Is  to  be  found  by  name. 

NAMED  is  the  name. 

Exceptions: 

USE_ ERROR  is  raised  If  LIST  Is  not  a  named  list  or  If  the  list  is  empty. 

SEARCH _ ERROR 

is  raised  If  NAMED  is  not  a  name  of  an  item  contained  in  the  list. 

5.4.1.10.  Extracting  a  lint-type  item  from  a  lint 


procedure  extract  (list: 

in 

LISTJTYPE; 

POSITION: 

in 

POSITION_COUNT; 

LIST_ITEM: 

out  LIST  JTYPE) 

procedure  extract  (list  : 

in 

LISTJTYPE ; 

NAMED: 

in 

NAME*  STRING; 

LIST_ITEM: 

OUt”  LIST_TYPE) 

procedure  extract  (LIST: 

in 

LISTJTYPE; 

NAMED: 

in 

TOKEN  TYPE; 

LIST  ITEM: 

OUt  LIST  TYPE); 

Purpose: 
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This  function  locales  a  list-type  item  in  a  list  and  returns  in  LIST_ITEM  a  copy  of  It. 
Subsequent  modifications  to  the  values  of  LIST  or  to  the  value  returned  in  LIST _ ITEM  do  not 
affect  the  other  value. 

Parameters: 

LIST  Is  the  list  containing  the  item  to  be  extracted. 

POSITION  is  the  position  within  the  list  that  identifies  the  item  to  be  extracted. 

LIST_ITEM  Is  the  value  of  the  list-type  Item  extracted. 

NAMED  Is  the  name  of  the  item  to  be  extracted.  It  may  only  be  used  with  named  lists. 


Exceptions: 

lrSE_ERROR  Is  raised  if  the  list  Is  empty  or  if  POSITION  has  a  value  larger  than  the  current 
length  of  the  list.  USE_ ERROR  Is  also  raised  if  NAMED  is  used  with  an  unnamed 
list  or  if  the  POSITION  specification  or  the  name  NAMED  identifies  an  item  not  of 
list-type  kind. 

SEARCH _ ERROR 

is  raised  If  there  is  not  Item  with  the  name  NAMED. 


5.4.1.17.  Replacing  a  list- type  item  in  >  list 

procedure  replace  (LIST :  in  out  LIST_TYFE; 

LISTITEM:  in  LIST~TYPE; 

POSITION  :  in  POSITION_COUNT) ; 

procedure  replace  (LIST:  in  out  LIST  TYPE; 

LISTITEM:  in  LIST~TYPE; 

NAMED  :  in  NAME~STRING) ; 

procedure  replace  (LIST:  in  out  list  TYPE; 

LISTITEM:  in  LIST~TYPE; 

NAMED  :  in  TOKEN  TYPE) ; 

Purpose: 

This  procedure  replaces  the  value  of  a  list-type  item  in  a  list.  Subsequent  modifications  to  the 
values  c'  LIST  or  of  LIST_ITEM  does  not  affect  the  other  value. 

Parameters: 

LIST  is  the  list  containing  the  Item  to  be  replaced. 

LIST  ITEM  Is  the  value  of  the  new  item. 


POSITION  is  the  position  within  the  list  that  Identifies  the  Item  to  be  replaced. 

NAMED  is  the  name  of  the  Item  to  be  replaced.  It  may  only  be  used  with  named  lists. 


Exceptions: 

L’SE_ ERROR  Is  raised  if  NAMED  Is  used  with  an  unnamed  list,  If  the  POSITION  specification  or 
the  name  NAMED  identifies  an  item  not  of  list-type  kind.  If  the  list  is  empty  or  or 
If  POSITION  hits  a  value  larger  than  the  current  length  of  the  list. 
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SBARCH_ ERROR 

Is  raised  if  there  is  no  item  with  the  name  NAMED. 


5.4.1.18.  Inserting  a  list-type  item  into  a  list 

procedure  insert  (list:  in  out  list_TYPE; 

LIST  ITEM:  in  LISTJPrPE; 
POSITION:  in  COUNT) ; 

procedure  insert  (list:  in  out  list_type; 


LIST_ITEM 

NAMED 

POSITION 


LIST_TYPE; 

NAME~STRING; 

count) ; 


procedure  insert(list:  in  out  list  type; 


LIST_ITEM 

NAMED 

POSITION 


LIST  TYPE; 
TOKEN_TYPE ; 
COUNT)"; 


Purpose: 

This  procedure  inserts  a  list-type  item  into  a  list  after  the  list  Item  specified  by  POSITION.  A 
value  of  zero  In  POSITION  specifies  a  position  at  the  head  of  the  list.  Subsequent  modifications 
to  the  values  of  LIST  or  of  LIST  ITEM  do  not  affect  it  other  value. 


Parameters: 


is  the  list  Into  which  the  Hein  will  be  Inserted. 


LIST_ITEM  is  the  value  of  the  item  to  be  Inserted. 

POSITION  Is  the  position  In  the  list  after  v  iilch  the  Item  Is  to  be  Inserted. 

NAMED  Is  the  name  of  the  new  Item.  Ii  may  only  be  used  with  named  or  empty  lists. 


Exceptions: 

USE_ ERROR  is  raised  if  an  attempt  is  mad 
conversely,  an  attempt  is  mad< 
LIST  is  a  named  list  that  alrc 
POSITION  specifies  a  value  lar 


to  insert  a  named  Item  Into  an  unnamed  list  or. 
to  Insert  an  unnamed  item  into  a  named  list  or  if 
ly  contains  an  Item  with  the  name  NAMED  or  if. 
■r  than  the  current  length  of  the  list. 


5.4.1.19.  Identifying  a  list-type  item  by  value  within  a  list 


function  pasiTiON_BY_VALUE(Lisrr  .  in  list_type: 

VALUE:  in  LIST  TYPE; 

START_POSI CION :  in  POSITION_COUNT 

:=  POSITION^COUNT' FIRST; 
END_POSITION  :  in  POSITION_COUNT 

:=  POSITION_COUNT ’LAST) 

return  position  count; 


Purpose: 

This  function  returns  the  position  at  which  the  next  list-type  Item  of  the  given  value  Is  located. 
The  search  begins  at  the  START_  POSITION  and  ends  when  either  an  Item  of  value  VALUE  Is 
found,  the  last  Item  of  the  list  has  been  examined,  or  the  Item  at  the  END  _  POSITION  has 
been  examined,  whichever  comes  first. 

Parameters: 
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LIST  is  the  list  In  which  the  position  of  an  item  is  to  be  found. 

VALUE  is  the  list-type  item  value. 

START  _  POSITION 

is  the  position  of  the  first  Item  to  be  considered  in  the  search. 

END  POSITION 

is  the  position  beyond  which  the  search  v.  ill  noi  proceed;  the  search  may  terminate 
prior  to  reaching  END _ POSITION  should  the  -.ought  list-type  item  be  found  or 
should  the  last  element  of  the  list  be  considered. 


Exceptions: 

USE_ERROR  Is  raised  if  START_POSITION  specifies  a  value  larger  than  the  current  length  of 
the  list,  if  the  list  is  empty  or  if  END  _  POSITION  is  less  than 
START  _  POSITION. 

SEARCH _ ERROR 

is  raised  if  the  VALUE  specified  is  not  found  within  the  region  specified  by 
START _ POSITION  and  END_POSITION. 

5.4.1.20.  Package  IDENTIFIER _ ITEM 

This  package  provides  interfaces  for  the  manipulation  of  list  items  whose  values  are  Identifiers  and  of 
names  of  list  Items.  Such  names  and  values  are  represented  Internally  as  values  of  type 
TOKEN  TYPE. 

5.4.1.20.1  Converting  an  identifier  to  a  token 

procedure  to  tokem (identifier:  in  name_strinG; 

TOKEN :  out  TOKEN  TYPE)  ; 

Purpose: 

This  procedure  converts  the  string  representation  of  an  Identifier  into  the  corresponding  internal 
token  representation. 

Parameters: 

IDENTIFIER  is  the  string  to  be  converted  to  a  toten. 

TOKEN  is  the  token  built  and  returned  according  to  the  value  of  IDENTIFIER. 


Exceptions: 

USK_ ERROR  is  raised  if  the  value  of  the  parameter  IDENTIFIER  does  not  conform  to  the  syntax 
of  an  Ada  identifier. 
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5.4.1.20.2  Converting  a  token  to  an  identifier 

function  TO_TEXT(LIST_ITEM :  in  TOKEN  TYPE) 
return  n are" string; 

Purpose: 

This  function  returns  the  external  representation  of  the  value  of  the  LIST  _  ITEM  parameter. 
The  external  representation  is  the  string  representation  defined  in  Section  5.4.  It  adheres  to  the 
syntax  required  for  NAME_STR1NG.. 

Parameters: 

LIST _ ITEM  Is  the  item  expressed  as  a  token. 


Exceptions: 

None. 

5.4.1.20.3  Determining  the  equality  of  two  tokens 
function  isequal  (tokeni  :  in  token  type; 

TOKENS :  in  TOKEN  TYPE) ; 

return  boolean; 

Purpose: 

This  function  returns  TRUE  if  the  two  tokens  TOKENI  and  TOKEN2  represent  Ada  identifiers 
whose  string  representation  is  equal  under  string  comparison,  excepting  differences  in  upper  and 
lower  case  notation;  otherwise,  it  returns  FALSE. 

Parameters: 


TOKENI.  TOKEN2 

are  the  tokens  whose  equality  Is  to  be  determined. 


Exceptions: 

None. 


5.4.1.20.4  Extracting  an  identifier  item  from  a  list 


procedure  EXTRACT  (LIST: 

POSITION: 


TOKEN: 


in  LIST  TYPE; 
in  position _count; 
out  TOKEN  TYPE)  ; 


procedure  extract (list:  in  list  type; 

NAMED:  in  NAME~ STRING; 

TOKEN :  OUt"  TOKEN  TYPE)  ; 


procedure  EXTRACT (LIST: 

NAMED: 

TOKEN: 


in  LIST  TYPE; 
in  TOKENTYPE; 

out  TOKEN  TYPE); 


Purpose: 

This  function  locates  an  identifier  Item  In  a  list  and  returns  in  TOKEN  a  copy  of  its  token. 
Parameters: 


LIST  is  the  list  containing  the  item  to  be  extracted. 
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POSITION  Is  the  position  within  the  list  that  Identifies  the  Iii'm  to  be  extracted. 

TOKEN  Is  the  token  representation  of  the  Identifier  Item. 

NAMED  Is  the  name  of  the  item  to  be  extracted.  It  may  only  be  used  with  named  lists. 

Exceptions: 

USE_ ERROR  is  raised  if  NAMED  is  used  with  an  unnamed  list  ,lf  the  POSITION  specification  or 
the  name  NAMED  identifies  an  Item  not  of  token  type  if  the  list  is  empty  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH  ERROR 

is  raised  if  there  Is  no  Item  with  the  name  NAMED. 


5.4.1.20.5  Replacing  an  identifier  item  in  a  list 


procedure  replace  (list: 

LIST_ITEM: 

POSITION: 


in,  out  LIST  TYPE; 
in  TOKEN  TYPE ; 

in  POSITION  COUNT) ; 


procedure  replace  (LIST: 

LISTITEM: 

NAMED 


in  out  LIST  TYPE; 
in  TOKENTYPE ; 

in  NAME  STRING)  ; 


procedure  replace  (list: 

LIST_ITEM: 


NAMED: 


in  out  LIST  TYPE; 
in  TOKENTYPE; 

in  TOKEN  TYPE) ; 


Purpose: 

This  procedure  replaces  the  value  of  an  Identifier  item  ;n  a  list. 
Parameters: 

LIST  is  the  list  containing  the  item  to  be  replaced. 

LIST  ITEM  is  the  new  value  of  the  item. 


POSITION  is  the  position  within  tic  list  that  identifies  the  item  to  be  replaced. 

NAMED  Is  the  name  of  the  Item  to  be  replaced.  It  may  only  be  used  with  named  lists. 


Exceptions: 

USE_ ERROR  Is  raised  If  NAMED  is  used  with  an  unnamed  list,  if  the  POSITION  specification  or 
the  name  NAMED  Identifies  an  item  not  of  Identifier  kind,  if  the  list  is  empty,  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 


SEARCH  _  ERROR 

is  raised  if  there  is  no  item  with  the  name  NAMED. 
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5.4.1.20.6  Inserting  an  identifier  item  into  a  list 


procedure  insert  (LIST: 

in  out 

LISTJTYPE; 

LIST_ITEH: 

in 

TOKENJTYPE; 

POSITION: 

in 

COUNT); 

procedure  insert  (LIST: 

in  out 

LISTJTYPE ; 

LIST_ITEM: 

in 

TOKENJTYPE; 

NAMED: 

in 

NAME  STRING 

POSITION: 

in 

COUNT) ; 

procedure  insert  (list: 

in  out 

LIST  TYPE; 

LIST_ITEM : 

in 

TOKENJTYPE; 

NAMED 

in 

TOKENJTYPE ; 

POSITION  : 

in 

COUNT)"; 

Purpose: 

This  procedure  inserts  an  identifier  item  into  a  list  after  the  list  Item  specified  by  POs  ON. 
A  value  of  zero  in  POSITION  specifics  a  position  at  the  head  of  the  list. 

Parameters: 

LIST  Is  the  list  Into  which  the  item  will  be  inserted. 

LIST_ITEM  Is  the  value  of  the  Item  to  be  inserted. 

POSITION  is  the  position  In  the  list  after  which  the  Item  is  to  be  Inserted. 


NAMED  Is  the  name  of  the  new  item.  It  may  only  be  used  with  named  or  empty  lists. 


Exceptions: 

USE _  ERROR  Is  raised  if  an  attempt  is  made  to  Insert  a  named  item  into  an  unnamed  list  or, 
conversely,  an  attempt  is  made  to  insert  an  unnamed  Item  into  a  named  list  or  if 
LIST  Is  a  named  list  that  already  contains  an  Item  with  the  name  NAMED. 
USE _ ERROR  Is  also  raised  ir  POSITION  specifies  a  value  larger  than  the  current 
length  of  the  list. 


5.4.1.20.7  Identifying  an  identifier  item  by  value  within  a  list 

function  position  by_value(list:  in  list  type: 

VALUE:  in  TOKENJTYPE; 

START  POSH  TON:  in  P0Sm0N_C0UNT 

:=  POSITION_COUNT’FIRST; 
END_P0SITI0N  :  in  POSITION  COUNT 

:=  PQSITI0N_C0UNT’LAST) 

return  position  count; 


Purpose: 

This  function  returns  the  position  at  which  the  next  Identifier  Item  of  the  given  value  Is  located. 
The  search  begins  at  the  START _ POSITION  and  ends  when  either  an  item  of  value  VALUE  is 
found,  the  last  Item  of  the  list  has  been  examined,  or  the  item  at  the  KND_ POSITION  has 
been  examined,  whichever  comes  first. 

Parameters: 

LIST  Is  the  list,  in  which  th"  position  of  an  item  Is  to  be  found  by  value. 
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VALUE  is  the  identifier  item  value  (token). 

START  _  POSITION 

is  the  position  of  the  first  item  to  be  considered  in  the  search.  END_POSITION 
is  the  position  beyond  which  the  search  will  not  proceed;  the  search  may  terminate 
prior  to  reaching  END  _ POSITION  should  the  sought  Identifier  item  be  found  or 
should  the  last  element  of  the  list  be  considered. 

Exceptions: 

USE_ERROR  Is  raised  if  START_POS!TION  specifies  a  value  larger  than  the  current  length  of 
the  list,  If  the  list  is  empty  or  If  END_  POSITION  Is  iess  than 
START  _POSlTION. 

SEARCH  _  ERROR 

Is  raised  if  the  VALUE  specified  Is  not  found  within  the  region  specified  by 
START  POSITION  and  END  POSITION. 


5.4.1.21.  Generic  package  INTEGER_ITEM 

This  is  a  generic  package  for  manipulating  list  Items  which  are  integers.  This  package  must  be 
instantiated  for  the  appropriate  Integer  type  (Indicated  by  NUMBER  In  the  specification). 

5.4.1.21.1  Converting  an  integer  item  to  ita  canonical  external  representation 

function  T0_TEXT  (LISTITEM :  in  NUMBER) 
return  string; 

Purpose: 

This  function  returns  the  external  representation  of  the  value  or  the  l,IST_ITKM  parameter. 
The  external  representation  is  the  string  representation  defined  In  Section  5.4. 

Parameters: 

LIST _ ITEM  is  the  integer  Item  whose  external  representation  Is  to  be  returned. 

Exceptions: 

None. 

5.4.1.21.2  Extracting  an  integer  item  from  a  Hat 

function  extract  (list:  in  list_type; 

POSITION:  in  POSITION_COUNT) 

return  number  ; 

function  extract  (list  :  in  list  type; 

NAMED:  in  NA«f  STRING) 

return  number; 

function  extract  (list  :  in  list_type; 

NAMED:  in  TOKEN  TYPE) 

return  number; 

Purpose: 

Page  3-281 

207 


PROPOSED  mil-std-cais 
31  JAM  ARY  19A.S 

This  function  locates  an  Integer  Item  in  a  list  and  returns  a  copy  of  Its  numeric  value. 
Parameters: 

LIST  Is  the  list  containing  the  Item  to  be  extracted. 

POSITION  Is  the  position  within  the  list  that  Identifies  the  item  to  be  extracted. 

NAMED  is  the  name  of  the  item  to  be  extracted.  It  may  only  be  used  with  named  lists. 


Exceptions: 

USE_ ERROR  Is  raised  if  NAMED  Is  used  with  an  unnamed  list,  if  the  POSITION  specification  or 
the  name  NAMED  identifies  an  Item  not  of  Integer  kind,  if  the  list  is  empty  or  If 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH _ ERROR 

Is  raised  if  there  is  no  item  with  the  name  NAMED. 

CONSTRAINT  _  ERROR 

Is  raised  If  the  value  to  be  extracted  violates  the  constraints  of  the  type  designated 
by  NUMBER. 


5.4.1.21.3  Replacing  an  integer  item  in  a  list 


procedure  replace  (list  :  in  out  listjtype: 

LISTITEM:  in  HUMBER; 

POSITION:  in  POSITION  COUNT) ; 


procedure  replace  (list:  in  out  LIST_TTPE ; 

LISTITEM:  in  NUMBER; 

NAKED:  in  NAME  STRING); 


procedure  replace  (list:  in  out  list_ttpe; 

LISTITEM:  in  NUMBER; 
NAMED  :  in  TOKEN  TYPE)  ; 


Purpose: 

This  procedure  replaces  the  value  of  an  integer  Hem  In  a  list. 
Parameters: 


LIST  is  the  list  containing  the  item  to  be  replaced. 


LIST  ITEM  Is  the  new  value  of  the  Item. 


POSITION  Is  the  position  within  the  list  that  Identifies  the  Item  to  be  replaced. 

NAMED  Is  the  name  of  the  item  to  he  replaced.  It  may  only  be  ti9ed  with  named  lists. 


Exceptions: 

USE_ERROR  is  raised  if  NAMED  Is  used  with  an  unnamed  list  or  If  the  POSITION  specification 
or  the  name  NAMED  identifies  an  item  not  of  Integer  kind,  if  the  list  is  empty  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 
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SBARCH_  ERROR 

is  raised  if  there  is  no  item  with  the  name  NAMED. 


5.4.1.21.4  Inserting  an  integer  item  into  a  Hat 


procedure  insert  (LIST: 

in 

out 

LIST_ITEM : 

in 

POSITION  : 

in 

procedure  insert  (list. 

in 

out 

LISTITEM: 

in 

NAMED 

in 

POSITION  : 

in 

procedure  insert  (list: 

in 

out 

LIST_ITEM : 

in 

NAMED: 

in 

POSITION  : 

in 

LIST_TYPE; 
NUMBER; 
COUNT) ; 

LIST_TYTE; 
NUMBER; 
KAMESTRING; 
COUNT) ; 

LIST_TYPE; 
NUMBER; 
TOKEN  TYPE; 
COUNT) ; 


Purpose: 

This  procedure  inserts  an  integer  item  Into  a  list  after  the  list  item  specified  by  POSITION.  A 
value  of  zero  in  POSITION  specifies  a  position  at  the  head  of  the  list. 


Parameters: 


f.IST 


Is  the  list  Into  which  the  Item  will  be  inserted. 


LIST_ITEM  is  the  value  of  the  item  to  be  inserted. 

POSITION  is  the  position  within  the  list  after  which  the  item  is  to  be  Inserted. 

NAMED  Is  the  name  of  the  new  item.  It  may  only  be  used  with  named  or  empty  lists. 


Exceptions: 

USE_  ERROR  is  raised  if  an  attempt  is  made  to  insert  a  named  item  Into  an  unnamed  list  or, 
conversely,  an  attempt  is  made  to  insert  in  unnamed  Item  into  a  named  list  or  ir 
I.IST  Is  a  named  list  that  already  contains  an  Item  with  the  name  NAMED. 
USE_  ERROR  Is  also  raised  If  POSITION  speriries  a  value  larger  than  the  current 
length  of  the  list. 


5.4.1.21.5  Identifying  an  integer  item  by  value  within  a  lint 
function  position_bt_value  (list  :  in  list_ttpe; 

VALUE:  in  NUMBER; 

START  POSITION:  in  POSITION  COUNT 

:=  POSITION  COUNT 'FIRST; 

ENDPOSITION:  ill  POSITION  _COUNT 

:=  POSITION  COUNT ’LAST) 

return  position  count; 

Purpose: 

This  function  returns  the  position  at  which  thp  next  Integer  Item  of  the  given  value  is  located. 
The  search  begins  at  the  START _ POSITION  and  ends  when  either  an  item  of  value  VALUE  is 
found,  the  last  Item  of  the  list  has  been  examined,  or  the  Item  at  the  END_  POSITION  has 
been  examined,  whichever  comes  first. 

Parameters: 


20fl 
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LIST  is  the  list  in  which  the  position  of  an  Item  is  to  be  found. 

VALUE  is  the  integer  Item  value. 

START  _  POSITION 

is  the  position  of  the  first  item  to  be  considered  in  the  search.  END _  POSITION 
is  the  position  beyond  which  the  search  will  not  proceed;  the  search  may  terminate 
prior  to  reaching  END_  POSITION  should  the  sought  integer  item  be  found  or 
should  the  last  element  of  the  list  be  considered. 


Exceptions: 

USE_ERROR  Is  raised  if  START _ POSITION  specifies  a  value  larger  than  the  current  length  of 
the  list,  if  the  list  is  empty  or  If  END  _  POSITION  Is  less  than 
START_  POSITION. 

SEARCI I  _  ERROR 

is  raised  or  the  VALUE  specified  is  not  found  within  the  region  specified  by 
START _ POSITION  and  END_POSITION. 

5.4.1.22.  Generic  package  FLOAT _ ITEM 

This  is  a  generic  package  for  manipulating  list  Items  which  are  floating  point  numbers.  This  package 
must  be  instantiated  for  the  appropriate  type  (Indicated  by  NUMBER  In  the  specification). 

5.4.1.22.1  Converting  a  floating  point  i f em  to  its  canonical  external 
representation 

function  to_text(list_item:  in  number 
return  string: 


Purpose: 

This  function  returns  the  external  representation  of  the  value  of  the  LIST_ITEM  parameter. 
The  external  representation  is  the  string  represen  atlon  defined  In  Section  5.4. 

Parameters: 

LIST  ITEM  is  the  floating  point  Item  whose  external  representation  Is  to  be  returned. 


Exceptions: 

None. 


5.4.1.22.2  Extracting  a  floating  point  item  from  a  list 

function  EXTRACT  (LIST:  in  LIST  TYPE; 

POSITION:  in  P0SITI0N_C0UNT) 

return  NUMBER; 

function  extract  (list,  in  list  ttpe; 

NAMED :  in  NAME~STRING) 

return  number; 

function  extract  (list:  in  listtype; 

NAMED:  in  TOKEN  TYPE) 
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return  number: 

Purpose: 

This  function  locates  a  floating  point  item  in  a  list  and  returns  a  copy  of  its  numeric  value. 
Parameters: 

LIST  Is  the  list  containing  the  Item  to  be  extracted. 

POSITION  is  the  position  within  the  list  that  identifies  the  item  to  be  extracted. 

NAMED  is  the  name  of  the  item  to  be  extracted,  it  may  only  be  used  with  named  lists. 

Exceptions: 

USE_ERROR  is  raised  if  NAMED  Is  used  with  an  unnamed  list,  If  the  POSITION  specification  or 
the  name  NAMED  identifies  an  item  not  of  floating  point  kind,  if  the  list  is  empty 
or  if  POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH _ ERROR 

is  raised  if  there  is  no  item  with  the  name  NAMED. 

CONSTRAINT  _  ERROR 

is  raised  if  the  value  to  be  extracted  violates  the  constraints  of  the  type  designated 
by  NUMBER. 

5.4.1.22.3  Replacing  a  floating  point  item  into  a  list 
procedure  replace  (list:  in  out  list_type: 

LlST_ITEM:  in  NUwiER; 

POSITION:  in  POSITION  COUNT)  ; 

procedure  replace  (list:  in  out  listjtpe; 

LIST  ITEM:  in  NUMbEr; 

NAMED:  in  NAMESTRING) ; 

procedure  replace  (list:  in  out  list_type; 

LIST_ITEM:  in  NUMBER; 

NAMED:  in  TOKEN_TYPE) ; 

Purpose: 

This  procedure  replaces  the  value  of  a  floating  point  item  in  a  list. 

Parameters: 

LIST  is  the  list  containing  the  Item  to  be  replaced. 

LIST _  ITEM  Is  the  new  value  of  the  item. 

POSITION  is  the  position  within  the  list  that  identifies  the  Item  to  be  replaced. 

NAMED  is  the  name  of  the  item  to  be  replaced.  It  may  only  be  used  with  named  lists. 

Exceptions: 

USE_ERKOR  is  raised  if  NAMED  Is  used  with  an  unnamed  list,  If  the  POSITION  specification  or 
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the  name  NAMED  Identifies  an  Item  not  of  floating  point  kind,  if  the  list  is  empty 
or  if  POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH  _  ERROR 

Is  raised  If  there  is  no  Item  with  the  name  NAMED. 


5.4.1.22.4  Inserting  a  floating  point  item  into  a  list 


procedure  INSERT  (LIST:  in  out  LIST_TYPE: 

LIST_ITEM:  in  NUMBER; 

POSITION:  in  COUNT) ; 


procedure  insert  (LIST:  in 

LIST_ITEM:  in 
NAMED:  in 

POSITION:  in 


OUt  LIST  TYPE; 
NUMBER; 
NAME_STRING; 
COUNT) ; 


procedure  insert  (list; 

LIST_ITEM : 

NAMED; 

POSITION: 


out  LISTTYPE; 
NUMBER; 
TOKEN  TYPE; 
COUNT); 


Purpose: 

This  procedure  inserts  a  floating  point  item  into  a  list  after  the  list  item  specified  by 
POSITION.  A  value  of  zero  In  POSITION  specifies  a  position  at  the  head  of  the  list. 

Parameters: 

LIST  Is  the  list  Into  which  the  item  will  be  Inserted. 

LIST_ITEM  Is  the  value  of  the  Item  to  be  Inserted. 

POSITION  Is  the  position  in  the  list  after  w  hich  the  Item  Is  to  be  inserted. 

NAMED  is  the  name  of  the  new  Item.  It  may  only  be  used  with  named  or  empty  lists. 

Exceptions: 

USE_ERROR  is  raised  if  an  attempt  is  mad  to  insert  a  named  Item  Into  an  unnamed  list  or, 
conversely,  an  attempt  is  madi  to  insert  an  unnamed  item  into  a  named  list  or  if 
LIST  Is  a  named  list  that  already  contains  an  item  with  the  name  NAMED. 
USE _  ERROR  Is  also  raised  if  POSITION  specifies  a  value  larger  than  the  current 
length  of  the  list. 


5.4.1.22.5  Identifying  a  floating  point  item  by  value  within  a  list 


function  POSITION  BY  VALUE  (LIST:  in  LIST_TYPE; 

VALUE  in  NUMBER 

STARTPOSITION.  in  POSITlONCOUNT 

:=  POSITIOn'cCUNC FIRST; 

END_POSITI  )N ;  in  POSITION~COUNT 

:=  POSITION~CPUNT'l  AST) 

return  position  count; 

Purpose: 

This  function  returns  the  position  at  which  the  next  floating  point  Hem  of  the  given  value  is 
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iocate.l  The  search  begins  at  the  START _ POSITION  and  ends  when  either  an  item  of  value 
VALUE  is  found  the  last  item  of  the  list  has  been  examined,  or  the  Item  at  the 
END _ POSITION  has  been  examined,  whichever  comes  first. 

Parameters: 

I.iST  Is  the  list  in  which  the  position  of  an  item  Is  to  be  found. 

VALUr,  is  th-  floating  point  item  value. 


ST  \RT_  POSITION 

is  the  position  of  the  first  Item  to  be  considered  In  the  search. 

END  PORTION 

Is  the  position  beyond  which  the  search  will  not  proceed:  the  search  may  terminate 
prior  to  reaching  END _  POSITION  should  the  sought  floating  point  item  be  found 
or  should  the  last  element  of  the  list  be  considered. 


Exceptions: 

LiSE_ ERROR  is  raised  if  START_ POSITION  specifies  a  value  larger  than  the  current  length  of 
the  list,  or  If  END_POSITION  Is  less  than  START_POSlTION. 

SEARCH _ ERROR 

is  raised  the  VALUE  specified  is  not  found  within  the  region  specified  by 
START  POSITION  and  END  POSITION. 


5.4.1.23.  Package  STRING-ITEM 

This  is  a  package  for  manipulating  list  items  which  are  strings.  The  external  representation  of  the 
value  of  a  string  Item  is  the  string  returned  by  an  EXTRACT  operation  applied  to  the  string  item. 

5.4.1.23.1  Extracting  a  string  item  from  a  list 


function  extract  (list:  in  list  type; 

POSITION:  in  POSITION_COUNT) 

return  string: 

function  extract  (list:  in  li  ttype; 

NAMED:  in  N/  STRING) 

return  STRING; 


function  extract  (LIST: 

NAMED: 

return  string; 


in  LI  .T_TYPE; 
in  TOKEN  TYPE) 


Purpose: 

This  function  locates  a  string  item  in  a  list  and  returns  a  copy  of  it  . 


Parameters: 

LIST  is  the  list  containing  tiu:  item  to  be  extracted. 

POSITION  is  the  position  within  the  list  that  Identifies  the  item  to  be  extracted. 
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NAMED  Is  the  name  of  the  Item  to  be  extracted.  It  may  only  be  used  with  named  lists. 


Exceptions: 

USK_ ERROR  Is  raised  if  NAMED  is  used  with  an  unnamed  list.  If  the  POSITION  specification  or 
the  name  NAMED  identifies  an  item  not  of  string  kind.  If  the  list  is  empty  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH _ ERROR 

is  raised  if  there  is  no  Item  with  the  name  NAMED. 


5.4.1.23.2  Replacing  a  airing  item  in  a  list 


procedure  replace  (LIST:  In  out  listjtype; 

LIST_ITEM:  In  STRING; 

POSITION:  in  POSITION  COUNT) ; 


procedure  replace  (LIST: 

LIST  ITEM: 


NAMED: 


in  out  LIST  TYPE; 
in  STRING: 

in  NAME  STRING)  ; 


procedure  replace  (LIST: 

LISTITEM: 

NAMED 


in  out  LISTJTYPE; 
in  string; 

in  TOKEN  TYPE); 


Purpose: 

This  procedure  replaces  the  value  of  a  string  Item  In  a  list. 

Parameters: 

LIST  Is  the  list  containing  the  item  to  be  replaced. 

LIST _ ITEM  is  the  new  value  of  the  Item. 

POSITION  Is  the  position  within  the  list  that  identifies  the  item  to  be  replaced. 

NAMED  Is  the  name  of  the  Item  to  be  replaced.  It  may  only  be  used  with  named  lists. 

Exceptions: 

USE_ ERROR  is  raised  If  NAMED  is  used  with  an  unnamed  list  or  if  the  POSITION  specification 
or  the  name  NAMED  identifies  an  Item  not  of  string  kind.  If  the  list  is  empty  or  if 
POSITION  has  a  value  larger  than  the  current  length  of  the  list. 

SEARCH  _  ERROR 

is  raised  If  there  is  no  item  with  the  name  NAMED. 


5.4.1.23.3  Inserting  a  string  item  into  a  list 

procedure  insert  (LIST:  in  out  list_ttpe; 

LISTITEM:  in  STRING; 
POSITION,  in  COUNT); 

procedure  insert(list:  in  out  list  type; 
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LIST_ITEM : 

in 

STRING; 

NAMED: 

in 

NAMESTRING, 

POSITION: 

in 

COUNT) ; 

ILIST : 

in 

out  LIST  TTPE; 

LIST_ITEM: 

in 

STRING; 

NAMED: 

in 

TOKENJTYPE; 

POSITION  : 

in 

COUNT)  ; 

Purpose: 

This  procedure  inserts  a  string  item  Into  a  list  after  the  list  Item  specified  by  POSITION.  A 
value  of  2ero  In  POSITION  specifies  a  position  at  the  head  of  the  list. 


Parameters: 

LIST  is  the  list  into  whlrh  the  item  will  be  inserted. 

LIST  ITEM  Is  the  value  of  the  Item  to  be  inserted. 


POSITION  Is  the  position  in  the  list  after  which  the  Item  Is  to  be  Inserted. 

NAMED  Is  the  name  of  the  new  Item.  It  may  only  be  used  with  named  or  empty  lists. 

Exceptions: 

USE_  ERROR  is  raised  If  an  attempt  Is  made  to  Insert  a  named  item  Into  an  unnamed  list  or. 

conversely,  an  attempt  is  made  to  Insert  an  unnamed  Item  Into  a  named  list  or  ir 
LIST  is  a  named  list  that  already  contains  an  Item  with  the  name  NAMED. 
USE_ ERROR  Is  also  raised  if  POSITION  specifies  a  value  larger  than  the  current 
length  of  the  list. 


5.4.1.23.4  Identifying  a  string  item  by  value  within  a  liat 


function  positiom_by_value  (list  ■ 

VALUE: 

START_POSITION : 
EXPOSITION 

return  position  count; 


in  list_ttpe: 
in  string; 

in  POSITIONCOUNT 

: =POSITION  COUNT-FIRST; 
in  POSITION  COUNT 

-POSITION  COUNT-LAST) 


Purpose: 

This  function  returns  the  position  at  which  the  next  string  Item  of  the  given  value  is  located. 
The  search  begins  at  the  START_POSlTION  and  ends  when  either  an  Item  of  value  VALUE  is 
found,  the  last  item  of  the  list  has  been  examined,  or  the  Item  at  the  END _ POSITION  has 
been  examined,  whichever  comes  first. 

Parameters: 

LIST  Is  the  list  In  which  the  position  of  an  Item  Is  to  be  found  by  value. 

VALUE  Is  the  string  item  value. 

START  _  POSITION 

Is  the  position  or  the  first  o-m  to  be  considered  In  the  search. 
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eni>_  position 

is  the  position  beyond  which  the  search  will  not  proceed;  the  search  may  terminate 
prior  to  reaching  END_ POSITION  should  the  sought  string  item  be  found  or 
should  the  last  element  of  the  list  be  considered. 

Exceptions: 

USE_ ERROR  Is  raised  If  START _ POSITION  specifies  a  value  larger  than  the  current  length  of 
the  list,  if  the  list  is  empty  or  if  ENT')  _  POSITION  Is  less  than 
START  _  POSITION. 

SKAIK'I  I  _  ERROR 

is  raised  if  the  VALUE  specified  is  noi  found  >  iihin  the  region  specified  by 
START  POSITION  and  END  POSITION. 


Exceptions: 

USE  ERROR  is  raised  If  POSITION  has  a  \  Uio  larger  than  the  current  length  of  the  list. 
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0.  NOTES 


8.1.  Keywords 

The  following  list  represents  the  keywords  applicable  to  this  standard.  These  keywords  may  be  used 
to  categorize  the  concepts  present  -d  within  this  standard  and  assist  in  automatic  retrieval  of 
appropriate  data  used  In  automated  document  retrieval  systems. 

Ad* 

APSE 

CAIS 

Concn  APSE  Interface  Set 
computer  file  eye tea 
KAPSE 

high  level  language* 

Inter facee 
interoperability 
operating  ayetea 
portability 

programming  support  environment 
software  engineering  environment 
transportability 
virtual  operating  system 
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Appendix  A 

PREDEFINED  RELATIONS,  ATTRIBUTES  AND 
ATTRIBUTE  VALUES 


Predefined  Relations: 

ACCESS:  designates  a  secondary  relationship  from  an  object  node  to  a  node  representing  a 

role;  the  access  rights  that  can  be  granted  to  adopters  of  the  role  are  given  In  the 
GRANT  attribute  of  this  relationship. 

ADOPTED  _  ROLE: 

designates  a  secondary  relationship  from  a  subject  (process)  node  to  a  node 
representing  a  role;  indicates  that  the  process  has  adopted  the  role  represented  by 
the  node. 

ALLOW  _  ACCESS: 

designates  a  secondary  relationship  from  a  process  node  to  a  node  representing  a 
role;  Indicates  that  the  process  can  create  relationships  of  the  predefined  relation 
ACCESS  from  an  object  to  this  node  representing  the  role. 

COUPLE:  designates  a  secondary  relationship  from  a  node  representing  a  queue  file  to  the 

node  representing  that  file's  coupled  file;  Indicates  that  the  queue  file  and  the  other 
file  are  coupled;  for  copy  queue  files,  this  means  the  contents  of  the  file  are  the 
Initial  contents  of  the  queue  file;  for  mimic  queue  files,  this  means  that  the  contents 
of  the  file  are  the  Initial  contents  of  the  queue  file  and  subsequent  writes  to  the 
queue  file  are  appended  to  the  other  file  as  well. 

CURRENT  _  ERROR: 

designates  a  secondary  relationship  from  a  process  node  to  a  file  node  representing 
the  file  to  which  error  messages  are  to  be  written. 

CURRENT  _  INPUT: 

designates  a  secondary  relationship  from  a  process  node  to  a  file  node  representing 
the  file  which  Is  currently  the  source  of  process  Inputs. 

CURRENT  _  JOB: 

designates  a  secondary  relationship  from  a  process  node  to  the  root  process  node  of 
the  tree  which  contains  the  process  node. 

CURRENT  _  NODE: 

designates  a  secondary  relationship  from  a  process  node  to  the  node  representing 
the  current  focus  of  attention  or  context  for  the  process'  activities. 

CURRENT_  OUTPUT: 

designates  a  secondary  relationship  from  a  process  node  to  a  file  node  representing 
the  file  to  which  outputs  are  currently  being  directed. 

CURRENT  _  USER: 

designates  a  secondary  relationship  from  a  process  node  to  a  top-level  node 
representing  the  user  on  whose  behalf  the  process  was  initiated. 

DEVICE:  designates  a  secondary  relationship  from  a  process  node  to  a  top-level  node 
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representing  a  device  to  which  the  process  has  access.  Also  designates  a  primary 
relationship  from  the  system-level  node  to  a  node  representing  a  device. 

DOT:  designates  the  default  relation  name  to  be  used  when  nope  is  provided.  Special 

rules  apply  for  pathname  abbreviations  in  the  presence  <>i  path  elements  whose 
relation  name  is  DOT.  No  other  semantics  are  associated  with  DOT. 

JOB:  designates  a  primary  relationship  from  the  top-level  node  of  a  user  to  the  root 

process  node  of  a  job. 

PARENT:  designates  the  secondary  relationship  from  a  given  node  to  the  node  which  is  the 

source  of  the  unique  primary  relationship  pointing  to  the  given  node. 

PERMANENT  _  MEMBER: 

designates  a  primary  relationship  from  a  node  representing  a  group  to  the  node 
representing  a  permanent  member  of  the  group. 

POTENTIAL  _  MEMBER: 

designates  a  secondary  relationship  from  a  node  representing  a  group  to  the  node 
representing  a  potential  member  of  the  group. 

STANDARD  _  ERROR: 

designates  the  secondary  relationship  from  a  process  node  to  a  file  node  representing 
the  standard  device  for  error  messages  for  the  whole  job. 

STANDARD  _  INPUT: 

designates  the  secondary  relationship  from  a  process  node  to  a  flic  representing  the 
standard  input  device  for  the  whole  job. 

STANDARD  _  OUTPUT: 

designates  the  secondary  relationship  from  a  process  node  to  a  file  node  representing 
the  standard  output  device  for  the  whole  job. 

USER:  designates  a  secondary  relationship  from  a  process  node  to  a  user's  top-level  node. 

Also  designates  a  primary  relationship  from  the  system-level  node  to  a  top-level 
node  representing  a  user. 

Predefined  Attributes: 

ACCESS  _  METHOD: 

applies  to  file  nodes;  designates  the  kind  of  access  which  can  be  used  on  the  node's 
contents;  possible  values  are  SEQUENTIAL,  DIRECT  and  TEXT. 

CURRENT  _  ST  ATUS: 

applies  to  process  nodes;  designates  the  current  status  of  the  node's  contents; 
possible  values  are  READY,  SUSPENDED,  ABORTED  and  TERMINATED. 

FILE _  KIND:  applies  to  file  nodes;  designates  the  kind  of  file  that  Is  the  node's  contents;  possible 
values  are  SECONDARY  _  STORAGE,  QUEUE,  TERMINAL  and 

MAGNETIC  TAPE. 
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FINISH_TIME: 

applies  to  process  nodes;  designates  the  implementation-defined  time  at  which  the 
process  terminated  or  aborted. 

GRANT;  applies  to  relationships  of  the  predefined  relation  ACCESS;  designates  the  access 

rights  which  can  be  granted  via  the  access  relationship;  values  are  lists  of  relevant 
grant  Items  as  specified  in  TABLE  II. 

HANDLES  _  OPEN: 

applies  to  process  nodes;  designates  the  number  of  node  handles  the  node's  process 
currently  has  opened. 

HIGHEST  _  CLASSIFICATION: 

applies  to  file  nodes;  designates  the  highest  allowable  object  classification  label  that 
may  be  assigned  to  the  node;  values  are  implementation-defined. 

IO  UNITS;  applies  to  process  nodes;  designates  the  number  of  GET  and  PUT  operations  that 
have  been  performed  by  the  node's  process. 

KIND:  applies  to  all  relationships;  designates  the  kind  of  the  target  node;  possible  values 

are  STRUCTURAL.  PROCESS  and  FILE. 

LOWEST  _  CLASSIFICATION: 

applies  to  file  nodes;  designates  the  lowest  allowable  object  classification  label  that 
may  be  assigned  to  the  node;  values  are  implementation-defined. 


MACHINE  _  TIME: 

applies  to  process  nodes;  designates  the  length  of  time  the  process  was  active  on  the 
logical  processor,  If  the  process  has  terminated  or  aborted,  or  zero,  If  the  process  has 
not  terminated  or  aborted. 

OBJECT  _  CLASSIFICATION; 

applies  to  all  nodes;  designates  the  node's  classification  as  an  object;  values  are 
implementation-defined. 

PARAMETERS: 

applies  to  process  nodes;  designates  the  parameters  with  which  the  process  was 
Initiated. 

QUEUE_KIND: 

applies  to  file  nodes  with  a  FILE _  KIND  attribute  value  of  QUI  UE:  designates  the 
kind  of  queue  file;  possible  values  are  SOLO,  MIMIC  and  COPY. 

RESULTS:  applies  to  process  nodes;  designates  the  Intermediate  results  of  the  process;  values 

are  user-defined. 

START_TIMK: 

applies  to  process  nodes;  designates  the  implementation-defined  l  ine  of  activation  of 
the  process. 

SUII.IECT_  CLASSIFICATION: 
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applies  to  process  nodes;  designates  the  classification  of  the  node's  process  as  a 
subject;  values  ar  implementation-defined. 

TERMINAL  _  KIND; 

applies  to  file  nodes  with  a  FILE  _  KIND  attribute  value  of  TERMINAL;  designates 
the  kind  of  terminal  which  is  represented  by  the  node's  contents:  possible  values  are 
SCROLL,  PAGE  and  FORM. 


Predefined  Attribute  Values: 

ABORTED 

APPEND 

APPEND  _  ATTRIBUTES 

APPEND  _  CONTENTS 

APPEND  _  RELATIONSHIPS 

CONTROL 

COPY 

DIRECT 

EXECUTE 

EXISTENCE 

FILE 

FORM 

MAGNETIC  _  TAPE 

MIMIC 

PAGE 

PROCESS 

QUEUE 

READ 

READ  _  ATTRIBUTES 
READ  _  CONTENTS 
READ  _  RELATIONSHIPS 
READY 
SCROLL 

SECONDARY_STORAGE 

SEQUENTIAL 

SOLO 

STRUCTURAL 

SUSPENDED 

TERMINAL 

TERMINATED 

TEXT 

WRITE 

WRITE_  ATTRIBUTES 
WRITE  _  CONTENTS 
WRITE  RELATIONSHIPS 
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Appendix  B 
CAIS  Specification 

This  appendix  contains  a  set  of  Ada  package  specifications  of  the  CAJS  interfaces  which 
compiles  correctly.  It  brings  together  the  interfaces  found  in  Section  5  using  the  Nested  Generic 
Subpackagcs  Implementation  approach.  Although  the  Interfaces  are  not  necessarily  shown  here 
in  the  order  in  which  they  are  discussed  In  the  text,  this  appendix  provides  a  reference  listing  of 
the  CAIS  as  well  as  an  illustration  of  the  generics  approach. 

with  CALENDAR; 
use  CALENDAR; 
package  CAIS  is 

package  node_definitions  is 

type  node  type  is  limited  private; 
type  NODEJCIND  is  (FILE.  STRUCTURAL,  PROCESS); 
type  INTENT_SPECIFICATIOW  is 
(EXISTENCE. 

READ. 

WRITE. 

READ  ATTRIBUTES, 

writEattributes. 

APPENDATTRIBUTES . 

READRELATIONSHIPS . 

WRITE_RELATIONSHIPS . 

APPEND JtELATXONSHIPS , 

REAUCONTENTS, 

WR ITE_CONTENTS . 

API’EHDCONTEXTS , 

CONTROL, 

EXECUTE, 

EXCL'USIVEJtEAD. 

EXCLUSIVEWRITE, 

EXCLUSIVEREAD  ATTRIBUTES. 

exclusive'write  attributes. 

EXCLUSrVEAPPEND  ATTRIBUTES. 

EXCLUSIVE_READ_RELATI ONSHI PS . 

EXCLUSIVE- WRITE_RELATI ONSHI PS . 

EXCLUSIVE_APPEND_RELATIONSHIPS , 

EXCLUS I VE~READ  CONTENTS. 

EXCLUSIVEjmiTE  CONTENTS, 

EXCLUSIVEAPPEND  CONTENTS. 

EXCLUSrVE_CONTROL) ; 

type  intention  Is  array  (positive  range  <>) 

of  INTENT_SPECIFICATION; 

subtype  namestring  is  string; 

subtype  relationship  key  is  string; 

subtype  relation  name  is  string; 

subtype  FORMSTRING  is  STRING; 


CURRENT_USER 

CURRENTNODE 

CURRENT_PROCESS 
LATESTJCEY 
DEFAULT_RELATION 
NO  DELAY 


constant  name  string  := 

••CURRENT  USER’ ; 

constant- name_string  :  = 

■ ’CURRENTNODE* ; 
constant  NAME  STRING  :=  *:*; 
constant  relationship  key  ;*  •»•; 
constant  relation_name  :=  *DOT’: 
constant  DURATION-:®  DURATION 'FIRST; 


STATUSERROR 
NAME  ERROR 


:  exception; 
:  exception; 
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USEJBROR 
LOCXERROR 
ACCESS  JJIOLATION 
INTENTJIOLATION 
SECURITYJIOLATIOH 

private 

type  NODE  JYPE  is 

(IMPLEMENTATIONJJEFINED) ; 

—  should  bs  dsflnsd  by  lsplsssn tor 
end  NODE  JEFINITIONS ; 

package  list_utilities  is 
use  NODE_DEFINITIONS ; 
type  LIST_TYPE  is  private: 
type  token  JYPE  is  private; 
type  LISTKIND  is  (UNNAMED,  NAMED.  EMPTY)  ; 
type  item”kind  is 

(LIST~  ITEM,  STRING  JCTEM. 

INTEGER  JTEM ,  FLOAT  JTEM .  IDENTIFIER  JTEM) ; 

type  count  is  range  o  . .  INTEGER 'LAST; 

subtype  listjext  is  string; 

subtype  position  count  is  count  range  count ‘first  ♦  1  . . 

COUNT 'LAST; 

procedure  copy  (to  LIST:  LIST_TYPE ; 

FROM_LIST:  LIST_TYPE) ; 

function  TO_LIST  (LIST  STRING :  STRING) 
return  LISTTYPE; 

function  TO  TEXT  (LIST  JTEM  :  LIST  TYPE) 
return  list_text; 

function  IS  EQUAL (LIST1 :  LIST  TYPE; 

LISTS:  LIST~TYPE) 
return  BOOLEAN; 

function  extract  (list  ;  list  type; 

POSITION  :  POSITION_COUNT) 
return  list_type; 

function  extract  (list  :  list_type; 

NAMED  :  NAME~STRIIfG) 
return  LIST  TYPE; 

function  extract  (list  :  list  type; 

NAMED  :  TOKEM_TYPE) 

return  listjype; 

procedure  replace  (list  :  in  out  list_type; 

LIST  ITEM  :  LIST  TYPE; 

POSITION  :  POSIT ION_COUNT)  ; 

procedure  replace  (list  :  in  out  list  type; 

LIST  ITEM  :  LIST_TYPE; 

NAMED  :  NAMESTRING) ; 

procedure  replace  (list  :  in  out  list_type; 

LIST  ITEM  :  LIST  TYPE; 

NAMED  :  TOKENJYPE)  ; 

procedure  insert  (list  :  in  out~LisT  type; 

LIST_ITEM  :  LISTJYPE; 

POSITION  ;  COUNT) ; 

procedure  insert(list  :  in  out  listjype; 

LIST_ITEM  :  LIST_TYPE; 

NAMED  :  NAME~STRING; 

POSITION  ;  COUNT) ; 

pr  cedure  insert  (list  :  in  out  listjype; 
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LIST  ITEM  :  LIST_TYPE; 

MAMED  :  TOKENJYPE; 

POSITION  :  COUNT)" ; 

function  position_by_value(list  :  list_type; 

VALUE  :  list” TYPE 
START  POSITION:  POSITION  COUNT 
:=  PCSITION_COUNT' FIRST; 

END  POSITION : “POSITION  COUNT 
:=  POSITION_COUNT 'LAST) 
return  position  count: 


function  set  extract 

(LIST  :  LIST  TYPE; 

POSITION  ;  POSITION_COUNT; 

LENGTH  ;  POSITIVE” :=  POSITIVE 'LAST) 
return  LISTJTEXT; 

procedure  splice  (list  :  in  out  list_type; 

POSITION  :  POSITION  COUNT; 
SUB_LIST  :  LISTJTEXT) ; 

procedure  splice  (list  :  in  out  list  type; 

POSITION  :  POSITION  COUNT; 
SUBLIST  :  LIST_TYPE) ; 

procedure  delete  (list  :  in  out  list_type; 

POSITION  :  P0SITI0M_C0UNT) ; 

procedure  delete  (list  :  in  out  listjiype; 

NAMED  :  NAMESTRING) ; 
procedure  DELETE  (LIST:  inout  LIST  TYPE; 

NAMED:  TOKEN  TYPE); 

function  get_list_kind(list:  list_type) 
return  LIST_KIND; 

function  get_item_kind(list  :  listtype) 
return  LISTJCIND; 

function  get  item  kind (list  :  list  type; 

POSITION  :  POSITIONCOUNT) 

return  itemkind: 

function  get  item  kindclist  :  list  type; 

NAMED  :  NAME~STRING) 

return  item  kind; 

procedure  MERGE  (FRONT  :  LIST  TYPE; 

BACX  :  list” TYPE; 

RESULT  :  in  out  LIST  TYPE)  ; 
function  length  (list  :  list_type)  return  count; 
procedure  item_name(list  ”  :  list  type; 

POSITION  :  POSITION_COUNT; 

NAME  :  OUt  TOITNjrYPE: 
NAME  RANGE  :  out  PC  JITTVE)  ; 
function  ITEM  NAME  (LIST  :  LIST  TYPE 

POSITION  :  POSITION  '  OUND 

return  name_string; 

function  POSITION_BY_NAME (LIST :  LIST  TYPE; 

NAMED:  NAME _ STRING) 

return  position_count; 

function  position_hy_name”  (list  :  list  type; 

NAMED  :  TOKENTYPE) 

return  position  type; 

function  text  length  (list  :  list  type) 
return  natural; 

function  text  length  (list  :  LIST  TYPE; 

POSITION  :  POS ITI 0N_C0UNT) 

return  positive; 
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function  TEXT_LENGTH  (LIST  :  LIST  TYPE; 

NAMED  :  NAME* STRING) 

return  PotiTTVE- 

function  text_length  (list  :  list  type; 

NAMED  :  TOKEN  TYPE) 

return  positive; - 

package  identifier_item  ia 

procedure  to  token  (identifier:  in  namestring; 

TOKEN :  out  TOKENTYPE)  ; 

function  to_text(list_item:  in  token  type) 
return  name_string; 

function  is  equal (tokeni ;  in  token  type; 

TOKENS:  in  TOKENTYPE) ; 
return  boolean; 


procedure  EXTRACT  (LIST:  in  LIST  TYPE; 

POSITION:  in  POSITION_COUNT; 

TOKEN :  out  TOKEN  lm»E)  : 

procedure  EXTRACT  (LIST:  in  LIST_TYPE; 

NAMED:  in  NAMESTRING; 

TOKEN :  out  TOKEN  TYPE)  ; 

procedure  extract  (LIST:  in  list  type: 

NAMED:  in  TOKEN  TYPE; 

TOKEN :  out  TOKEN  TYPE)  ; 

procedure  REPLACE  (LIST:  in  out  list  type; 

LISTJtTEM:  in  TOKEN  TYPE; 
POSITION:  in  POSITION_COUNT) ; 

procedure  replace  (LIST:  in  out  list  type; 

LIST_ITEM :  in  TOKEN  TYPE; 

NAMED:  in  TOKEN  TYPi); 

procedure  replace  (LIST:  in  out  LISTTYPE; 

LIST_ITEM:  in  TOKEN  TYPE; 

NAMED:  in  TOKEN  TYPE); 

procedure  insert  (LIST:  in  out  list  type; 

LIST_ITEM:  in  TOKENTYPE; 

POSITION:  in  COUNT)? 

procedure  INSERT  (LIST:  in  out  list_type; 

LIST_ITEN:  in  TOKENTYPE; 

NAKED:  in  NAME_STRING; 

POSITION:  in  COUNT); 

procedure  insert  (LIST:  in  out  listtype; 

LIST_ITEM:  in  TOKEN_TYPE; 

NAMED:  in  TOKEN_TYPi ; 

POSITION:  in  COUNT); 

function  position_by_value(list:  in  list_type; 

VALUE:  in  TOKEN  TYPE; 
START_POSITION:"in 
POSITION  COUNT  := 
POSITION-COUNT ’FIRST ’ 
ENO_POSITION?  in 

"POSITION  COUNT  := 
POSITION-COUNT’LAST) 
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return  position_count; 

end  IDENTIFIER_ITEM; 

generic 

type  number  is  range  <>; 
package  integer_item  is 


function  extract 

(LIST 

:  LIST_TYPE; 

POSITION 

:  POSITION  COUNT) 

return 

NUMBER; 

function  EXTRACT 

(LIST  : 

LIST  TYPE; 

NAMED  :  NAME  STRING) 

return 

NUMBER; 

function  extract 

(LIST  : 

LIST  TYPE; 

NAMED  :  TOKEN  TYPE) 

return 

NUMBER; 

procedure  replace 

(LIST 

:  in  Out  LIST  TYPE; 

LIST  ITEM  :  NUMBER; 

POSITION 

:  POSITION_COUNT) ; 

procedure  replace 

(LIST 

:  in  OUt~LIST  TYPE; 

LIST  ITEM  :  NUMBER; 

NAMED 

.  NAMESTRING) ; 

procedure  replace 

(LIST 

:  in'out  LIST  TYPE; 

LIST  ITEM  :  NUMBER; 

NAMED 

:  TOKENTYPE) ; 

procedure  insert 

(LIST 

:  in  out  LIST  TYPE; 

LIST  ITEM  :  NUMBER; 

POSITION 

:  COURT); 

procedure  insert 

(LIST 

:  in  out  LIST  TYPE: 

LIST  ITEM  :  NUMBER; 

NAMED 

:  NAME  SIRING 

POSITION 

:  COUNT); 

procedure  insert 

(LIST 

:  in  out  LIST  TYPE; 

LIST  ITEM  :  NUMBER; 

NAMED 

:  TOKEN  TYPE; 

POSITION 

:  COUNT);  * 

function  position 

BYVALUE 

(LIST  :  LIST  TYPE; 

VALUE  :  NUMBER; 

STARTPOSITION: 


POSITION  COUNT: =  POSITION  COUNT ‘FIRST; 

~  EXPOSITION:  POSITION  COUNT 
:=  POS ITION _COUNT ‘ LAST) 

return  position_count ; 
end  integeritem; 
generic 

type  number  is  digits  <>; 
package  flqat_item  is 

function  to_text(list_item:  number) 


return  string; 

function 

EXTRACT 

(LIST 

:  LIST  TYPE: 

POSITION 

:  POSITION_COUNT) 

return 

NUMBER; 

function 

EXTRACT 

(LIST  : 

LIST_TYPE; 

NAMED  : 

NAMESTRING) 

return 

NUMBER; 

function 

EXTRACT 

(LIST  : 

LIST  TYPE; 

NAMED  :  TOKEN_TYPE) 
return  number; 

procedure  replace  (list  :  in  out  list_ttpe; 

LIST  ITEM  :  NUMBER; 

POSITION  :  POSITIONCOUNT) ; 

procedure  replace  (list  :  in  out~Lisr  type; 

LISTITEM  :  NUMBER; 

NAMED  :  NAME  STRING) ; 
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procedure  replace  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  TOKEN  TYPE) ; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

POSITION  :  COUNT) ; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEK  :  NUMBER; 

NAMED:  NAME  STRING; 

POSITION  : “COUNT); 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  NAME  STRING; 

POSITION  :  COUNT) ; 

function  POSITION_BY_ VALUE  (LIST  :  LIST  TYPE; 

VALUE  :  NUMBER; 

START_POSITION : 

POSITION_COUMT:=  position_count"first; 

END_POSITION: 

POSITION_COUNT: ~  POSITION  COUNT’LAST) 

return  position  count: 
end  float  item; 
package  stringitem  is 

function  extract  (list  :  list  type; 

POSITION  :  POSITION  COUNT) 

return  string; 

function  EXTRACT  (LIST  ;  LIST  TYPE; 

NAMED  ;  NAME  STRING) 

return  string; 

function  extract  (list  :  list  type; 

NAMED  :  TOKEN  TYPE) 
return  STRING; 

procedure  replace  (list  :  in  out  list _ty  e; 

LIST_ITEM  ;  STRING; 

POSITION  :  POSITICNCOUNT) ; 
procedure  replace  (list  :  in  out  list  ty  e; 

LIST_ITEM  :  STRING; 

NAMED  :  NAMESTRING) ; 

procedure  replace  (list  :  in  out  list  type; 

LIST_ITEM  :  STRING; 

NAMED  :  TOKEN  TYPE); 

procedure  insert  (list  :  in  out  list_ttpe; 

LIST_ITEM  :  SIRING; 

POSITION  :  COUNT) ; 

procedure  insert  (list  :  in  out  list_type; 

LIST_ITEM  :  STRING; 

NAMED  :  NAME  STRING; 

POSITION  :  COUNT) ; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  :  STRING; 

NAMED  :  TOKEN  TYPE; 

POSITION  :  COUNT)” ; 

function  position_by_value  (list  list  type; 

“value  ;  STRING 
START_POSITION :  P0SITI0N_C0UNT 

:=  POSITION  COUNT "FIRST; 

END_POSITION:  POSITION_COUNT 

:=  POSITION  COUNT "LAST) 

return  position  count; 
end  STRING  ITEM; 

private 

type  TOKEN  TYPE  is  ( IMPLEMENT ATION_DEFINED)  ; 

—  should  bs  dsflnsd  by  lsplsasntor 
type  LIST_TYPE  is  (IMPLSMENTATIONDEFINED)  ; 
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--  should  b«  defined  67  lsplesentor 


end  LIST_UTILITIES ; 
package  ~NCDE_MANAGEXENT  is 
use  NOCE_DEFINITIONS; 

type  ncde  iterator  is  limited  private; 

subtype  relationship  jceypattern  Is  relationshipjcey; 

subtype  RELATION_NAME_PATTERN  is  RELATION  NAME ; 


procedure  open 


(NODE 

in  out  NODE  TYPE; 

NAME 

NAME  STRING,” 

INTENT 

INTENTION  :=  (1  =>  READ); 

TIMELIMIT 

DURATION  :=  N0_DELAY) ; 

procedure  open 

(NODE 

in  out  NODE  TYPE; 

BASE 

NODE  TYPE; 

KEY 

RELATIONSHIP  JCEY; 

RELATION 

RELATI  ON  NAME  :  = 

DEF  AULT_RELATI ON ; 

INTENT 

INTENTION  ;=  (1  =>  READ); 

TIME_LIMIT 

DURATION  :=  N0_DELAY) ; 

procedure  close 

(NODE  :  in  OUt  NODE  TYPE) 

procedure  change_intent 

(NODE 

in  out  NODE  TYPE: 

INTENT 

INTENTION; 

TIME_LIMIT 

DURATION  ; =  NODELAY) ; 

function  is  open 

(NODE  :  NODE  TYPE) 

return  BOOLEAN); 

function  INTENT_0F 

(NODE  :  NODE  TYPE) 

return  intention; 

function  GET  ITEM  KIND  (NODE  :  NODE  TYPE) 

return  NODE  KIND; 

function  primary  name 

(NODE  :  NODE  TYPE) 

return  NAMi  sTRiNG; 

function  primarykey 

(NODE  :  NODETYPE) 

return  relationship  key; 

function  primaryrelation  (node  ;  node  type) 

return  relati onname; 

function  pathjcey 

(NODE  :  N0DE_TYPe7 

return  relationship  key; 

function  path  relation 

(NODE  :  NODEJTYPE) 

return  relation  name; 

function  basepath 

(NAME  :  NAMESTRING) 

return  name  string; 

function  LAST  RELATION  (NAME  :  NAME  STRING) 


function 

LAST  KEY 

return  relation_name; 

(NAME  :  NAMESTRING) 

function 

IS_0BTAINABLE 

return  relationship  key 

(NODE  :  N0DE_TYPE) 

function 

ISOBTAINABLE 

return  boolean; 

(NAME  :  NAMESTRING) 

function 

IS  OBTAINABLE 

return  boolean; 

"(BASE 

NO'  E  TYPE; 

KEY 

REI  ATI0NSHIP_KEY; 

RELATION  : 

RE!  ATI ON  NAME  :  = 

DEf  AULT_RELATI ON) 
return  boolean; 

function  is_same  (nodei  :  node_type; 

NODES  :  NODETYPE) 

return  boolean; 
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function  is  same  (mamei  :  name_string; 

NAMES  :  NAME_STRING) 

return  boolean; 


procedure  getparext 
(PARENT 
NODE 
INTENT 
TIME_LIMIT 

procedure  copy  node 
(FROM 
TO  BASE 

to'key 

TOJtELATION 

procedure  copy_node 

procedure  copy  tree 
(FROM 
TO  BASE 
TO~KEY 
TO~RELATION 

procei 1  ire  C0PY_TREE 


in  out  NODE_TYPE; 
NODE_TYPE ; 

INTENTION  :=  (I  =>  READ); 
DURATION  : =  NODELAY) ; 

NODE_TYPE ; 

NODEJTYPE; 

RELATIONSHIPJCEY; 

:  RELATION_NAMl  :  = 
DEFAULT_RELATION) ; 

(FROM  T  NODETYPE; 

TO  :  NAME_STRING) ; 

NODETYPE; 

NODE~TYPE ; 

RELATIONSHIP  JCEY; 

RELATI ON_NAME  := 

DEFAULT  RELATION) ; 

(FROM  r  N0DE_TYPE ; 

TO  :  NAME  STRING); 


procedure  rename 
(NODE 
NEW  BASE 

new'key 

new'relation 

procedure  rename 

procedure  delete_nooe 
procedure  deletenode 
procedure  delete_tree 
procedure  deletetree 
procedure  link 

(NODE 
NEWBASE 
NEW_ KEY 

new”relation 
procedure  link 


NODE  TYPE; 

NODE_TYPE; 

RELATIONSHIPJCEY; 

RELATION  NAME  := 

DEFAULT  RELATION) ; 

(RODE  ”  :  NODEJTYPE ; 

NEW  NAME  :  NAMESTRINC) . 
(NODE  :  In  out  NODE  TYPE)  ; 
(NAME  :  NAME  STRINC)-; 

(NODE  :  in  OUt  NODE  TYPE)  ; 
(NAME  :  NAMESTRING) ; 

:  NODETYPE ; 

:  NODE~TYPE ; 

:  RELATIONSHIPJCEY ; 

:  RELATION_NAME  := 

DEFAULT  RELATION); 

(NODE  :  _NODE  TYPE; 

NEW  NAME  :  NAME  STRING); 


procedure  unlink 
(BASE 
KEY 

RELATION 

procedure  unlink 
procedure  iterate 

(ITERATOR 

NODE 

KIND 

KEY 


NODE  TYPE; 

RELATIONSHIPJCEY; 

RELATION  NAME  := 

DEFAULT  RELATION); 

(NAME  :  NAME_STRING) ; 

:  out  NODE_ ITERATOR; 

:  NODE  TYPE": 

:  NODEJCIND; 

:  RELATIONSHIP_KEY_PATTERN  := 


RELATION 
PRIMARY  ONLY 


**»; 

:  RELATION  NAME  PATTERN  := 
default  Relation  ; 

;  BOOLEAN- : =  TRUE) ; 


procedure  iterate 

(ITERATOR 

NAME 

KIND 

KEY 


out  NODE_ITERATOR ; 

NAME  STRING; 

NODE-KIND; 

RELATIONSHIP  KEYPATTERN  := 
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RELATION 

PRIMARYONLY 
function  more 

procedure  cet  next 

(ITERATOR 
NEXT_NODE 
INTENT 


:  R£LATION_NAME_PATTERN  := 
DEFAULT_RELATION ; 

:  BOOLEAN- : =  TRUE) ; 
(ITERATOR  :  NODE_ITERATOR) 
return  boolean; 

in  Out  NODE  ITERATOR; 

in  out  node'type; 

INTENTION  := 


(1  =>  EXISTENCE) ; 


TIMELIMIT  ;  DURATION  :=  NO_DELAY) ; 

procedure  set_current_nqde  (node  :  node  "type)  ; 
procedure  set-current-node  (name  :  name~string) ; 
procedure  cet-current~node  (node  :  in  out  node  type; 

INTENT  "  :  INTENTION  ;=  (1  =>  EXISTENCE) 
TIME  LIMIT  :  DURATION  :  =  NO  DELAY); 


private 

type  NODE  ITERATOR  is 

( IMPLEMENT ATIONDEFINED) ; 

—  should  b«  dsflnsd  by  laplsasntor 

end  NODEMANAGEMENT; 

package  attributes  ia 
Uae  NODEDEFINITIONS; 
uae  list  utilities; 

aubtype  attributename  is  STRING; 

type  attribute_iterator  ia  limited  private; 

aubtype  attribute  PATTERN  ia  STRING; 

procedure  CREATE  NODE  ATTRIBUTE 

(NODE-  :  NODETYPE; 
ATTRIBUTE  :  ATTRIBUTE  NAME; 
VALUE  .  LISTTYPE) ; 
procedure  create  node  attribute 

(NAME  NAME  STRING; 

ATTRIBUTE  :  ATTRIBUTENAME ; 
VALUE  :  LISTTYPeF ; 
procedure  create  path_attr i Bute 

(BASE  NODE  TYPE; 

KEY  :  RELATIONSHIP  KEY; 

RELATION  :  RELATION  NAME  :  = 
DEFAULT_RELATI ON ; 
ATTRIBUTE  :  ATTRIBUTE  NAME; 
VALUE  .  LIST_TYPE7; 
procedure  create  path  attribute 

(NAME-  NAME  STRING; 

ATTRIBUTE  ;  ATTRIBUTE  NAME; 
VALUE  :  LISTTYPE)  ; 
procedure  delete  node_attribute 

(NODE-  NODE  TYPE; 

ATTRIBUTE  :  ATTRIBUTENAME) ; 

procedure  delete  node  attribute 

(NAME-  NAME  STRING; 

ATTRIBUTE  :  ATTRIBUTE_NAME)  ; 

procedure  delete  pathattribute 

(BASE-  NODE  TYPE; 

KEY  :  RELATIONSHIPKEY; 

RELATION  :  R£LATION_NAME  := 
DEFAULT_RELATION ; 
ATTRIBUTE  :  ATTRIBUTE  NAME) ; 


Page  3-304 


wo 


procedure  deletf  _path_attr i bute 

(NAME  :  NAME  STRING; 


ATTRIBUTE  :  ATTR I BUTE_NAME ) ; 

procedure  set_node_attrisute 

(NODE  ~  :  NODE_TYPE; 

ATTRIBUTE  :  ATTRIBUTE_NAME ; 

VALUE  :  LISTJTYPE)  ; 

procedure  set  node  attribute” 

(NAME  ”  :  NAMESTRING; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST  TYPeF ; 

procedure  set  path  attribute  ” 

(BASE  ”  ;  NODE_TTPE; 

KEY  ;  RELATIONSHIP JCEY; 

RELATION  :  RELAT I □  NNAME  :  = 
DEFAULT_RELATION ; 
ATTRIBUTE  :  ATTRIBUTE_NAME; 

VALUE  :  LIST_TYPE) ; 

procedure  set  path  attribute 

(NAME  ;  NAMESTRING; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  ;  LISTJTYPEj" ; 

procedure  get_node_attribute 

(NODE  ”  :  NODE  TYPE; 

ATTRIBUTE  :  ATTRIBUTENAME; 

VALUE  :  in  out  LIST  TYPE)  ; 
procedure  get  node  attribute 

(NAME  ~  :  NAMESTRING; 

ATTRIBUTE  ;  ATTRIBUTENAME ; 

VALUE  :  in  out  LIST  TYPE)  ; 

procedure  get  path  attribute 

(BASE  “  :  NODEJTYPE ; 

KEY  :  RELATIONSHIP  KEY; 

RELATION  .  RELATION  NAMi  :  = 
DEFAULTRELATION; 
ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  in  out  LIST  TYPE)  ; 
procedure  get  path  attribute 

(NAME  ~  :  NAMESTRING; 

ATTRIBUTE  :  ATTRIBUTENAME ; 

VALUE  :  in  out  LIST  TYPE)  ; 

procedure  node  attribute  iterate 

(ITERATOR  :  OUt  ATTRISUTE_ITERATOR: 
NODE  :  NODE  TYPE; 

PATTERN  :  ATTRIBUTE  PATTERN  :  =  •*•) ; 

procedure  node  attribute  iterate 

(ITERATOR  jut  ATT3ISUTE_ITERAT0R; 
NAME  :  NAMESTRING; 

PATTERN  .  ATTRIBUTE  PATTERN  :=  ••*) ; 

procedure  path_attribute_itera~ 

( ITERATOR  :  o”ut  ATTRIBUTE  ITERATOR; 
BASE  :  NODEJTYPE; 

KEY  ;  RELATIONSHIP  KEY; 

RELATION  :  RELATION_NAME  := 
DEEAULT_RELATION; 

PATTERN  .  ATTR I BUTE_PA TTERN  ; =  •«■); 

procedure  path_attri bute _ iterate  ” 

(ITERATOR  ;  out  ATTRIBUTE  ITERATOR; 
NAME  :  NAME_STRING; 

PATTERN  ;  ATTRIBUTE  D,  TTERN  :=  «•*); 

function  more 

(ITERATOR  :  ATTRIBUTE  ITERATOR) 


procedure  get  next 


return  boolean; 


(ITERATOR  :  in  out  ATTRIBUTE  ITERATOR; 
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ATTRIBUTE  :  out  ATTRIBUTE_NAME; 
VALUE  ;  in  OUt  LIST  TYPE)  ; 


private 

type  ATTRIBUTE_ITERATOR  is  (IMPLEMENTATION_DEFINED)  ; 
—  should  bs  defined  bjr  lsplesentor 

end  ATTRIBUTES; 

package  access_control  is 
use  N0DEJ5EFINITI0NS; 

subtype  grant_value  is  cais.list_utilities.list_type; 
procedure  set  access  control 

(NODE  ”  :  N0DE_TYPE ; 

R0LE_N0DE  :  NOD£”tYPE; 

GRANT  ;  GRANT_VALUE ) ; 

procedure  set_access_control 

(NAME  :  NAMESTRING; 

ROL£_NAME  :  NAME~STRING; 

GRANT  :  GRANT_VALUE) ; 

function  is  granted 


(OBJECT_NODE 

ACCESS_RIGHT 

function  is  granted 


procedure  adopt 


procedure  unadopt 
end  ACCESSCONTROL; 

package  structuralnodes  is 
use  NODEDEFINITIONS; 
use  LIST_UTILITIES ; 

procedure  create_node 

(NODE 

BASE 

KEY 

RELATION 

ATTRIBUTES 
ACCESS  CONTROL 
LEVEL  " 

procedure  creatb_node 
(node” 

NAME 

ATTRIBUTES 
ACCESS  CONTROL 
LEVEL  ” 

procedure  create_node 
(BASE” 

KEY 

RELATION 

ATTRIBUTES 
ACCESS_CONIROL 
LEVEL  ” 

procedure  createnode 
(name” 


:  NODE_TYPE ; 

:  NAME~STRING) 

return  boolean; 

(08JECTNAME  :  NAMESTRING; 
ACCESSRIGHT  :  NAMESTRING) 

return  boolean; 

(ROLE_NODE  :  NODE_TYPE; 

ROLE  KEY  :  RELATIONSHIP  KEY  := 
LATEST  KEY)  ; 

(ROLE'kEY  :  RELATIONSHIP_KEY) ; 


:  in  OUt  NODE_TYPE; 

:  NODE_TYPE; 

:  RELATIONSHIP_KEY  ; = 

LATEST  KEY; 

:  RELATION_NAME  := 
DEFAULT_RELATION ; 

:  LIST  TYPE  :=  EMPTY_LIST; 

:  LIST”TYPE  :=  EMPTY~LIST; 

:  FORM~STRING  :=  EMPTY_LIST) ; 

;  in  out  NODE_TYPE ; 

:  NAME  STRING,” 

:  LIST~TYPE  :=  EMPTY  LIST; 

:  LIST~TYPE  :=  EMPTy”lIST; 

:  FORM'STRING  :=  EMPTY_LIST) ; 

;  NODE  TYPE; 

:  RELAT IONSHIP_KEY  := 
LATEST_KEY ; 

.  RELATION_NAME  .= 
DEFAULT_RELATION ; 

:  LIST_TYPE  :=  EMPTY_LIST; 

:  LIST-TYPE  :=  EMPTY”lIST; 

:  F0Rm”sTRING  :=  EMPTY_LIST) ; 

:  NAME  STRING; 
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ATTRIBUTES 
ACCESS  CONTROL 
LEVEL  ~ 

end  STRUCTURAL  NODES ; 

package  process_definitions  ie 
UM  N0DEJ5EFINITI0NS ; 
use  list'utilities ; 

type  process  status  is 

(READY.”  SUSPENDED.  ABORTED.  TERMINATED) ; 

subtype  results_list  is  cais.list_utilities.list_type 
subtype  results_string  is  string; 
subtype  parameter_list  is  cais.list_utilities.list_type 

rootprocess  :  constant  NAME  STRING  :=  ••CURRENT  JOB* 
currEnt  input  :  constant  name~string  :  = 

* -CURRENT_ INPUT* ; 

CURRENT  OUTPUT  :  constant- NAME  STRING  :  = 

*  ,CURRENT_OUTPVrr“; 

CURRENT  ERROR  :  constant  NAME  STRING  :  = 

* ' CURRENT_ERROR ■ ; 

end  PROCESSDEFINITIONS; 

package  process  control  is 
use  NODEDEFINITIONS; 
use  list'utilities; 
use  PROcisS  DEFINITIONS; 


procedure  spawnprocess 

(NODE  :  in  out  NODE  TYPE; 

FILENODE  :  NODE_TYPE ; 

INPUTPARAMETERS  :  PARAMETER_LIST  := 

KEY  :  RELATIONSHIPKEY  := 

LATESTKEY; 

RELATION  :  RELATION_NAME  := 

DEFAULT_RELATION ; 

ACCESS  CONTROL  :  LIST  TYPE_:=  EMPTY  LIST. 

LEVEL  ~  :  LIST  TYPE  :=  EMPTY_LIST ; 

ATTRIBUTES  :  LIST_TYPE  := 

EMPTY  LIST; 

INPUT_FILE  :  NAMESTRING  ;= 

CURRENT_INPUT ; 

OUTPUT_FILE  :  NAMESTRING  := 

CURRENT  OUTPUT; 

ERROR _FILE  :  NAME_STRING  := 

CURRENT_ERROR ; 

ENVIRONMENT  NODE  .  NAMESTRING  := 

CURRENT_NODE) ; 

procedure  await  process  completion 

(NODE  “  :  NODE  TYPE; 

TIME_LIMIT  :  DURATION  :=  DURATION ’LAST) ; 

procedure  await  process  completion 

(NODE  ~  :  NODE  TYPE; 

R£SULTS_RETURNED  :  in  out  RESULTS_LIST; 

STATUS  ”  :  out  PROCESS  STATUS; 

TIME_LIMIT  :  DURATION 

DURATION -LAST) ; 

procedure  invoke_process 

(NODE-  :  in  out  NODE  TYPE; 

FILE  NODE  :  NODE  TYPE; 


2.T.1 


;  LIST_TYPE  ;=  EMPTY_LIST; 

:  LIST_TYPE  :=  EMPTY-LIST; 

:  FORMSTRING  :=  EMPTYLIST) ; 
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RESULTSRETURNED 

STATUS 

INPUTPARAMETERS 

KEY 


in  out  R£SULTS_LIST ; 
out  PROCESSSTATUS ; 
PARAMETER_LIST  :=  •*; 
RELATIONSHIP  KEY 


procedure 


procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 


RELATION 

ACCESS  CONTROL  . 
LEVEL  ~ 
ATTRIBUTES 

INPUT_FILE 

OUTPUT_FILE 

ERROR_FILE 

ENVIRONMENTNODE 

TIME  LIMIT 


LATEST_KEY ; 

:  RELATION_NAME  := 
DEFAULT_RELATION ; 

LIST_TYPE~:=  EMPTY_LIST; 

:  LIST  TYPE  :=  EMPTY_LIST ; 

:  LIST^TYPE  := 

EMPTY_LIST ; 

:  HAME_STRING  := 
CURRENT_INPUT; 

:  NAMESTRING  := 
CURRENT_OUTPUT ; 

:  NAME  STRING  = 
CURRENT_ERROR ; 

:  NAMESTRING  := 
CURRENT_NODE ; 

:  DURATION  := 

DURATION -LAST) ; 


CREATE  JOB 
(FILE"  NODE 
INPUT  PARAMETERS 
KEY 

ACCESSCONTROL  : 

LEVEL 

ATTRIBUTES 

INPUTFILE 

OUTPUTFILE 

ERROR  FILE 


:  NODE  TYPE; 

;  PARAMETERLIST; 

:  RELATIONSHIP  KEY  := 
LATEST  KEY; 

LIST  TYPE  :=  EMPTYLIST; 

:  LIST  TYPE  :=  EMPTY  LIST; 
:  LIST~TYPE  := 

EMPTY  LIST; 

:  NAME  STRING  := 

CURRENT JCNPUT: 

:  NAME  STRING  := 

CURRENT  OUTPUT; 

:  NAMESTRING  := 

CURRENT  ERROR; 


ENVIRONMENT  NODE 


NAMESTRINC  ;= 
CURRENT  USER); 


APPENDRESULTS 
(RESULTS  :  RESULTSSTRING) ; 
•RITERESULTS 

(RESULTS  :  RESULTS  STRING); 


GET  RESULTS 
(NODE 
RESULTS  : 
GET_RESULTS 
(NODE 
RESULTS  : 
STATUS 
GET  RESULTS 
(NAME 
RESULTS  : 
STATUS  : 
GET  RESULTS 
(NAME 


N0DE_TYPE ; 

in  out  RESULTS  LIST)  ; 
NODE_TYPE ; 

in  out  RESULTS  LIST; 
OUt  PROCESS_STATUS)  ; 

NAMESTRINC; 

in  out  RESULTS  LIST; 

OUt  PROCESS_STATUS )  ; 

NAME  STRING; 


RESULTS  :  in  out  RESULTS_LIST) ; 


GET_PARAMETERS 

(PARAMETERS  in  OUt  PARAMETER  LIST)  ; 


ABORTPROCESS 
(NODE  :  NODE  TYPE; 

RESULTS  :  RESULTSSTRING) ; 

ABORT  PROCESS 
(NAME  :  NAME  STRING; 

RESULTS  :  RESULTS  STRING) ; 

ABORT  PROCESS  "  (NODE  :  NODE  TYPE) ; 
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procedure  abort  process 

(NAME  :  NAMESTRING) ; 

procedure  suspendprocEss 

(NODE  :  NODEJIYPE) ; 

procedure  suspend'process 

(NAME  NAME~STRING) ; 

procedure  resumeprocess 

(NODE  :  NODEJIYPE); 

procedure  resume  process 

(NAME  :  NAMESTRING) ; 

function  status_of  process 

(NODE  :  NODEJIYPE) 
return  PROciss_STATUS ; 

function  status_of_process 

(NAME  :  NAMESTRING) 

return  process  status; 

function  handles  open 

(NODE  :  NODEJIYPE) 

return  natural; 

function  handles  open 

(NAME  :  NAMESTRING) 

return  natural; 

function  iounits 

(NODE  :  N0DE_TYPE) 
return  natural; 

function  iounits 

(NAME  :  NAMESTRING) 

return  natural; 

function  start  jtime 

(NODE  :  NODEJYPE) 

return  timE; 

function  starttime 

(NAME  :  NAMESTRING) 
return  tim£; 

function  finish  time 

(NODE  :  NODE  TYPE) 

return  timE; 

function  finish  time 

(NAME  :  NAMESTRING) 

return  timE; 

function  machinetime 

(NODE  :  NODE  TYPE) 
return  duration; 

function  machinetime 

(NAME  :  NAMESTRING) 
return  duration; 

end  processcontrol; 

package  iojjefinitions  ia 
uae  NODEDEFINITIONS; 
uae  LISTUTILITIES; 

type  file  type  ia  limited  private; 
tyre  FILE  MODE  ia 

(IN  FILE.  INOUT  FILE.  OUT_FILE, 

APPENDFILE) ; 

type  character  array  ia  array  (character) 

of  BOOLEAN; 

type  FUNCTION_KEY_DESCRIPTOR (LENGTH  ;  POSITIVE)  is  private; 
type  TABENUmErATION  ia  (HORIZONTAL,  VERTICAL); 
type  position  type  ia 
record 

ROW  :  NATURAL; 

COLUMN  :  NATURAL: 
end  record; 
private 

type  FILEJTYPE  ia  (IMPLEMENTATION_DEFINED)  ; 

—  abonld  b*  dafinad  by  laplaacnior 

type  FUNCTION  KEY  DESCRIPTOR (LINK:  POSITIVE)  is 

record 

null:  —  defined  by  lapleaentor 
end  record; 

end  IO_DEFINITIONS; 

package  io_control  ia 

uae-IO_DEFINITIONS ; 
uae  NODE_DEFINITIONS; 
uae  LIST~UTILITIES; 
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procedure  open  file  node 

(FILE  ”  :  FILE  TYPE; 

NODE  :  in  OUt  NODE  TYPE; 

INTENT  :  in  INTENTION; 

TINE_LINIT  ;  in  DURATION  :=  NODELAY) ; 

procedure  synchronize 

(FILE  :  FILE_TYPE) ; 
procedure  set  log 

(FILE  :  FILE  TYPE; 

L0G_FILE  :  FILE'TYPE) ; 

procedure  clear Jlog (file  :  file_type); 
function  logging  "(file  :  filetype) 

return  boolean; 

function  cet_log  (file  :  file  type) 

return  file_type; 
function  number_of_elements  (file  :  file_type) 

return  NATURAL; 


procedure  set_prompt 
function  GET  PROMPT 


(TERMINAL  :  FILE  TYPE; 
PROMPT  :  STRING-)  ; 
(TERMINAL  :  FILE_TYPE) 

return  string; 


function  interceptedcharacters 

procedure  enablefunctionkeys 

function  functionkeysenabled 

procedure  couple 

(queue  base 

QUEUEJCEY 
QUEUE_RELATI0N 
FILE_N0DE 

form” 

ATTRIBUTES 
ACCESS  CONTROL 
LEVEL 

procedure  couple 


(TERMINAL  :  FILE  TYPE) 

return  characterarray; 

(TERMINAL  :  FILE_TYPE; 

ENABLE  :  BOOLEAN) ; 

(TERMINAL  :  FILE  TYPE) 
return  boolean; 

NODE  TYPE; 

RELATIONSHIP  KEY 
LATESTKEY; 

RELATION  NAME  := 

DEFAULT  RELATION; 

NODE  TYPE; 

LISTTYPE  ;=  EMPTYJLIST; 

LIST  TYPE;  —  intentionally  no  default 
LIST-TYPE  ;*  EMPTY  LIST: 

F0RM~STRING  :=  EMPTY  LIST); 


(QUEUE  NAME 
FILE_N0DE 
FORM 

ATTRIBUTES 
ACCESS_C0NTR0L 
LEVEL  " 

procedure  couple 

(QUEUE_BASE 

queuejcey 

QUEUE_RELATION 


NAMESTRING; 

node”type; 

LISTJYPE  :=  EMPTY  LIST; 

list"type; 

LISt”tYPE  :=  EMPTY_LIST; 
FORMSTRING  :=  EMPTY_LIST) ; 

N0DE_TYPE ; 

RELATIONSHIP  KEY  := 

LATEST  KEY; 

RELATION  NAME  :  = 

DEFAULT  RELATION; 


FILENAME 

form” 

ATTRIBUTES 
ACCESS  CONTROL 
LEVEL  “ 

procedure  :ouple 

(QUEUE_NAME 

FILE_NAME 

form" 

ATTRIBUTES 
ACCESS  CONTROL 
LEVEL  ” 


NAME  STRING; 

LIST_TYPE  ;=  EMPTY  LIST; 
LIST-TYPE; 

LIST-TYPE  :=  EMPTY_LIST; 
F0RM”STRING  :=  EMPTY_LIST) ; 

NAMESTRING; 

NAME~STRING; 

LISt”tYPE  :=  EMPTY_LIST; 
LIST-TYPE; 

LIST~TYPE  :=  EMPTY  LIST; 
FORm"sTRING  :=  EMPTY  LIST); 
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end  iocontrol: 
generic 

type  ELEMENT  JTYPE  is  private; 
package  directio  is 
use  NODE_DEFINITIONS; 
use  LIST_UTILITIES ; 
use  IO_DEFINITIONS ; 

type  count  is  range  o  . .  integer-  at  . 

subtype  positive_count  is  count  range  1  ..  count 'last; 

—  Fils  aanagsatnt 


procedure  CREATE  (FILE 
BASE 
KEY 

RELATION 

MODE 

FORM 

ATTRIBUTES 

ACCESS  CONTROL  : 
LEVEL  “ 

procedure  create  (FILE 
NAME 
MODE 

FORM 

ATTRIBUTES 


:  in  out  FILE_TYPE ; 
NODE_TYPE; 
RELATIONSHIP^ Y  :  = 


LATEST_KEY; 
RELATION  NAME  := 
DEF  AULT_RELATI ON ; 
FILE  MODE 
INOUT  FILE 
LIST_TYPE 
EMPTYLIST 
LIST  TYPE 
EMPTY  LIST 
LIST_TYPE 
FORM  STRING 


EMPTYLIST; 

=  EMPTY  LIST) ; 


:  in  Out  FILE  TYPE; 
NAJ  ESTRING; 

FIl  E  MODE  :* 

INC  T  FILE; 

LIS,  TYPE  := 

EMP  .'  LIST; 

LIST  TYPE  := 


procedure  open 


procedure  OPEN 


EMF  nf_LIST; 

ACCESSCONTROL  :  LISIJTYPE  :=  EMPTYLIST; 
LEVEL  ”  :  FORMSTRING  ;=  EMPTY  LIST); 

(FILE  :  in  out  FILE  TYPE; 

NODE  :  NODE  TYPE; 

MODE  :  FILE  MODE  :  =  INOUT  FILE); 

(FILE  ;  in  "out  FILE  TYPE* 

NAME  :  NAMESTRING; 

MODE  :  FILE  MODE  :=  INOUT  FILE); 


procedure  close  (file 
procedure  delete  (file 
procedure  RESET  (FILE 
MODE  : 


:  in  Out  FILEJTYPE)  ; 
;  in  out  FILEJPfPE)  ; 
:  in  OUt  FILE- TYPE; 
FILE  MODE); 


function  mode  (file  :  filejtype)  return  file_mode; 
function  name  (file  :  file’type)  return  string; 
function  form  (file  ;  file  type)  return  string; 


function  is  open  (file  :  filejtype)  return  boolean; 
—  Input  snd  output  operations 

procedure  READ  (FILE  :  FILE_TYPE; 

ITEM  :  OUt  ELEMENT JTYPE ; 

FROM  ;  POSITIVE_COUNT) ; 

procedure  read  (file  ;  filejtype  : 

ITEM  :  OUt  ELEMENT  JTYPE)  ; 
procedure  WRITE  (FILE  :  FILE  TYPE; 
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ITEM  :  ELEMENT_TYPE; 

TO  :  POSITIvi  COUNT) ; 
procedure  write  (file  :  file  type; 

ITEM  :  ELEMEJfTTYPE) ; 

procedure  set_index  (file  :  file_type: 

TO  :  POSITIVE_COUNT) ; 

function  index  (FILE  :  file_type)  return  positive_count; 
function  SIZE  (FILE  :  FILE~TYPE)  return  COUNT; 

function  END_OF_FILE  (FILE  :  FILE_TYPE)  return  BOOLEAN; 

end  direct_io; 

generic 

type  element  type  is  private; 
package  sequehtial_io  is 
use  NODE_DEFINITIONS; 
use  LISTJUTILITIES; 
use  10  DEFINITIONS; 


—  Fils  aanagsasnt 


procedure 


CREATE  (FILE 
BASE 
KEY 


RELATION 


MODE 


FORM 


ATTRIBUTES 


procedure 


ACCESS  CONTROL 
LEVEL  ~ 

CR-ATE  (FILE 
NAME 
MODE 


FORM 


ATTRIBUTES 


procedure 

procedure 


ACCESS  CONTROL 
LEVEL  ” 


OPEN 


OPEN 


(FILE 
NODE  : 
MODE  : 

(FILE 
NAME  : 
MODE  : 


;  in  out  FILE_TYPE; 
NODE  TYPE; 
RELATIONSHIP  KEY  :  = 
LATEST_KEY; 

RELATION  NAME 
DEFAULT ^RELATION ; 
FILE  MODE 
INOUT  FILE 
LIST_TYPE 
EMPTY  LIST 
LIST_TYPE 
EMPTY  LIST 
LIST_TYPE 
F0RM~STRIMG 
;  in  out  FILE  TYPE; 
NAMESTRINC; 
FILE~M0DE  := 

INOUT  FILE; 

LIST  TYPE  := 

EMPTY  LIST; 
LIST_TYPE  := 

EMPTY  LIST; 
LIST_TYPE 
FORM  STRING 
:  in  out  FILE_TYPE; 

NODE  TYPE; 

FILE~M0DE) ; 

:  in  out  FILE_TYPE; 

NAME  STRING; 

FILE" MODE  ); 


EMPTY  LIST; 

*  EMPTY  LIST) 


EMPTY  LIST; 

=  EMPTY  LIST) 


procedure  CLOSE  (FILE 
procedure  delete  (file 
procedure  reset  (file 

MODE  : 

procedure  reset  (file 


:  in  out  FILE_TYPE) ; 
:  in  out  FILE  "type)  ; 
:  in  out  FILE  "type; 
FILE  MODE) ; 

:  in  out  FILE  TYPE)  ; 


function  mode  (file  :  file_type)  return  file  mode; 
function  name  (file  :  file  "type)  return  string; 
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function  form  (file  :  filejtype)  return  string; 
function  is_0PEN  (file  :  file_type)  return  boolean; 

—  Input  and  output  operation* 
procedure  read  (file  :  file_type; 

ITEM  ;  out  ELEMENT JIYPE) ; 

procedure  write  (file  :  filejtype;- 

ITEM  :  ELEMENT_TYPE) ; 

function  end_of_file  (file  :  file  type)  return  boolean; 
end  sequenti al_io  ; 

package  text  io  is 

use  node_definitions  ; 

use  LIST~UTILITIES; 
use  IO_oiriNITIONS ; 

type  count  is  range  o  . .  integer ‘last; 

subtype  positive_count  is  count  range  1  . .  count -last; 

unbounded  :  constant  COUNT  :=  0;  —  line  and  page  length 

subtype  field  is  integer  range  o  ..  integer -last; 
subtype  number  base  is  integer  range  3  . .  is; 

type  TYPE  SET  is  (LOWER  CASE.  UPPER_CASE)  ; 


File  Managesent 


procedure  create  (FILE 
BASE 
KEY 

RELATION 

MODE 

FORM 

ATTRIBUTES 

ACCESS  CONTROL 
LEVEL  ~ 

procedure  create  (file 
name 

MODE 

FORM 

ATTRIBUTES 

ACCESS_C0NTR0L 
LEVEL  “ 


:  in  out  file  type; 

NODE  TYPE; 

RELATIONSHIP  KEY  := 

LATEST  KEY  ; 

RELATION  NAME  := 

DEF  AULT_R£LATI ON ; 

FILE  MODE  :~ 

INOUT  FILE; 

LIST  TYPE  := 

EMPTY  LIST; 

LIST  TYPE 
EMPTY  LIST; 

LIST  TYPE  EMPTY  LIST; 
FORM~STRING  :=  EMPTr_LIST)  ; 
:  in  "out  FIl  E_TYPE ; 
NAME_STRING; 

FILE~M0DE  := 

INOUT  FILE; 

LIST  TYPE  := 

EMPTY  LIST; 

LIST  TYPE  := 

£MPTY_LIST; 

LISTTYPE  :=  EMPTYLIST; 
FORM_STRING  ; =  EMPTY  LIST) ; 


procedure  open  (file  :  in  out  file  type; 


NODE  :  N0DE_TYPE ; 

MODE  :  FILE~M0DE) ; 

procedure  open  (file  :  in  out  file  type; 

NAME  :  NAME  STRING; 

MODE  :  FILE~M0DE) ; 
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procedure  close  (file  :  in  out  filejtype)  ; 
procedure  delete  (file  :  in  out  file  jype)  ; 
procedure  reset  (file  :  in  out  filejtype; 

MODE  :  FILEMODE) ; 

procedure  reset  (file  :  in  "out  filejtype)  ; 

function  mode  (file  :  filejtype)  return  file_mode; 
function  name  (file  :  file'type)  return  STRiiio; 
function  FORM  (FILE  :  FILE  TTPE)  return  STRING; 

function  iaOPEN  (file  :  file_type)  return  boolean; 


—  Control  of  default  input  end  output  filea 
procedure  SETJNPUT  (FILE  :  FILE_TYPE) ; 

procedure  set'output  (file  :  filejtype); 

procedure  setjerror  (file  ;  filejtype)  ; 


function  standard_ input  return  filejtype; 
function  standardjutput  return  filejtype; 
function  standard~erro«  return  file  type; 

function  cuhrent_input  return  file_type; 
function  current~outfut  return  file" TYPE; 
function  current_error  return  file  type; 


--  Specification  of  Um  and  page  lengtba 

procedure  SETLINELENGTH  (FILE  :  FILEJTYPE; 

TO  :  COUNT)-: 
procedure  SET  LINE  LENCTH  (TO  :  COUNT); 

procedure  setpaCELENCTH  (FILE  :  FILE_TYPE; 

TO  ;  COUNT)-; 
procedure  set  page  length  (to  :  count); 

function  linelength  (file  .  file_type)  return  count-. 
function  linelength  return  count; 

function  page  length  (file  :  file  type)  return  count; 
function  page  length  return  count; 


—  Column.  Lina  and  Page  Control 

procedure  Newsline  (file  :  filejtype; 

SPACING  :  POSITIVE_COUNT  :*  1) ; 
procedure  Newsline  (spacing  :  positive_count  :=  1); 

procedure  skip_line  (file  :  file_ttpe; 

SPACING  :  POSITIVE_COUNT  :=  1); 

procedure  sxip_line  (spacing  :  positive_count  :*  i); 

function  end_of_line  (file  ;  file_type)  return  boolean; 
function  end”of  "line  return  boolean; 

procedure  nct  page  (file  :  file  jype)  ; 
procedure  newj»age; 

procedure  skippage  (file  :  file_type)  ; 
procedure  SKIPPAGE; 
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function  end_of_page  (file  :  file  type)  return  boolean; 
function  end  of  pace  return  boolean; 

function  end  of  file  (file  .  file  type)  return  boolean; 
function  end  of  file  return  boolean; 


procedure  set_col  (file  :  file_type; 

TO  :  POS ITIVE_COUNT) ; 
procedure  SET_COL  (TO  :  POSITIVE jtount)  ; 

procedure  SET  LINE  (FILE  :  FILE  TYPE; 

TO  :  POSITIVE_COUNT) ; 
procedure  set_line  (to  :  positivejiount)  ; 


function  col  (file  :  file  type)  return  positive  count; 
function  col  return  positive  count; 

function  line  (file  :  file  type)  return  positive  count; 
function  line  return  positive  count; 

function  page  (file  :  file  type)  return  positive  count; 
function  page  return  positive  count; 

—  Character  Input-Output 

procedure  get  (FILE  :  FILE_TYPE; 

ITEM  :  out  CHARACTER); 
procedure  GET  (ITEM  :  out  CHARACTER); 
procedure  PUT  (FILE  :  FILE  TYPE;  ITEM  :  CHARACTER)  ; 
procedure  put  (item  .  CHARACTER) ; 


—  String  Input-Output 

procedure  GET  (FILE  :  FILE_TYPE;  ITEM  :  out  STRING); 

procedure  get  (item  :  out  'string)  ; 

procedure  PUT  (FILE  ;  FILE  TYPE,  ITEM  :  STRING) ; 

procedure  PUT  (item  :  string); 

procedure  getline  (file  :  file_type; 

ITEM  :  out  STRING; 

LAST  :  out  NATURAL)  ; 
procedure  GET  LINE  (ITEM  :  out  STRING; 

LAST  :  OUt  NATURAL); 

procedure  PUT_LINE  (FILE  :  FILE_TYPE;  ITEM  :  STRING); 
procedure  put'line  (item  :  string); 


—  generic  package  for  Input-Output  of  Integer  Tjrpee 
generic 

type  num  is  range  <>; 
package  integer  io  is 

DEFAULT_WIDTH  :  FIELD  :=  NUM 'WIDTH; 

DEFAULT~BASE  :  NUMBER_BASE  : =  10; 

procedure  GET  (FILE  :  FILE  TYPE; 

ITEM  :  OUt  NUM; 

WIDTH  :  FIELD  :=  0); 
procedure  get  (item  .  out  NUM; 
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WIDTH  :  FIELD  0); 

procedure  put  (file  :  file  type; 

ITEM  :  MUM; 

WIDTH  :  FIELD  :=  DEFAULT  WIDTH; 

BASE  :  MUMBERBASE  :=  DEFAULT  BASE) ; 
procedure  PUT  (ITEM  :  HUM;  - 

WIDTH  :  FIELD  :=  DEFAULT  WIDTH; 

BASE  :  MUMBERBASE  :=  DEFAULT_BASE) ; 

procedure  get  (from  :  string; 

ITEM  :  out  HUM; 

LAST  :  out  POSITIVE)  ; 
procedure  PUT  (TO  ;  out  string: 

ITEM  :  MUM; 

BASE  :  MUMBERBASE  :*  DEFAULT_BASE) ; 

end  INTEGER  10; 


—  generic  package  for  Input-Output  of  Floating  Point 

—  Typae 

generic 

type  mum  ia  digits  <>; 
package  float_io  ia 

DEFAULTFORE  :  FIELD  :=  2; 

DEFAULT~AFT  ;  FIELD  :=  MUM 'DIGITS  -  1; 

DEFAULT  EXP  :  FIELD  3: 


procedure  GET  (FILE  r  FILEJYPE; 

ITEM  ;  out  NUN; 

WIDTH  :  FIELD  : =  0) ; 
procedure  get  (ITEM  ;  out  MUM; 

WIDTH  ;  FIELD  :»  0) ; 

procedure  PUT  (FILE  :  FILE  TYPE; 

ITEM  :  MUM; 

FORE  :  FIELD  :=  DEFAULT  FORE; 

AFT  :  FIELD  ;=  DEFAULT- AFT; 

EXP  :  FIELD  :=  DEFAULT~EXP) ; 

procedure  put  (item  :  mum; 

FORE  :  FIELD  :=  DEFAULT_FORE ; 

AFT  :  FIELD  :=  DEFAULT~AFT ; 

EXP  :  FIELD  :=  DEFAULTJSXP) ; 

procedure  GET  (FROM  ;  STRING; 

ITEM  :  OUt  NUM; 

LAST  ;  out  POSITIVE)  ; 
procedure  PUT  (TO  ;  out  STRING; 

ITEM  :  NUM; 

AFT  :  FIELD  ;=  DEFAULT  AFT; 
EXP  :  FIELD  :»  DEFAULT-EXP) ; 

end  FLOAT  10; 


—  ganarlc  package  for  Input-Output  of  Fixed  Point  Typee 

generic 

type  num  ia  delta  <>; 
package  fixed  io  ia 
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DEFAULT_FORE  :  FIELD  :=  NUM 'FORE; 

D£FAULT~AFT  :  FIELD  :=  HUM 'AFT; 

DEFAULT~EXP  :  FIELD  :=  0; 

procedure  get  (file  :  file  type; 

ITEM  .  OUt  NUM.- 
WIDTH  :  FIELD  :=  0); 

procedure  get  (item  :  out  num.- 
width  :  FIELD  :=  0); 

procedure  PUT  (FILE  :  FILE_TYPE ; 

ITEM  :  MUM; 

FORE  :  FIELD  :=  DEF AULT_F0R£ ; 
AFT  :  FIELD  :=  DEFAULTJUT; 
EXP  :  FIELD  :=  DEFAULT_EXP) ; 
procedure  put  (ITEM  :  HUM; 

FORE  :  FIELD  :=  DEF AULT_F0RE ; 
AFT  :  FIELD  ;=  DEFAULT~AFT; 
EXP  :  FIELD  :=  DEF AULT~EXP) ; 

procedure  get  (from  :  string; 

ITEM  :  out  NUM: 

LAST  :  OUt  POSITIVE)  ; 
procedure  put  (to  :  out  string; 

ITEM  :  NUM; 

AFT  :  FIELD  :=  DEFAULTAFT; 
EXP  :  FIELD  :=  DEFAULTEXP) ; 

end  FIXED  10; 


—  gwnwrlc)  package  for  Input-Output  of  Enumeration  Type* 
generic 

type  enum  ia  (<»; 
package  enumerationio  ia 

DEFAULT  WIDTH  ;  FIELD  :=  0; 

DEFAULT~SETTING  :  TYPESET  ;=  UPPERCASE; 

procedure  GET  (FILE  :  FILE_TYPE;  ITEM  ;  Out  ENUM)  ; 
procedure  get  (item  :  out  enum); 

procedure  put  (file  :  file_type; 

ITEM  :  ENUM;  ” 

WIDTH  :  FIELD  :=  DEFAULT  WIDTH; 

SET  :  TYPE_SET  : =  DEFAULT_SETTING) ; 
procedure  put  (item  .-  enum; 

WIDTH  :  FIELD  :=  DEF AULT_W IDTH ; 

SFT  ;  TYPE_SET  ; =  DEFAULT_SETTING) ; 

procedure  get  (from  .  string, 

ITEM  :  out  ENUM; 

LAST  :  OUt  POSITIVE); 

procedure  put  (to  :  out  string; 

ITEM  :  ENUM; 

SET  :  TYPE  SET  : =  DEFAULT_SETTING) ; 
end  ENUMERATION  IO; 

end  TEXT  IO; 

package  scroll  terminal  ia 

U8e  N0DE_DEF I N ITI 0NS ; 

USe  10  DEFINITIONS; 
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procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 


procedure 

function 

function 

function 

function 

procedure 


procedure 


procedure 


procedure 

function 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 

procedure 


(KIND  :  TAB  ENUMERATION  :»  HORIZONTAL; 
COUNT  :  POSITIVE  :=  1); 

BELL 

(TERMINAL  :  FILE  TYPE) ; 

BELL; 

PUT  (TERMINAL  :  FILE_TYPE; 

ITEM  :  CHARACTER) ; 

PUT  (ITEM  :  CHARACTER) ; 

PUT  (TERMINAL  :  FILEJTYPE; 

ITEM  ;  STRING) ; 

PUT  (ITEM  :  STRING) ; 

SET  ECHO 

(TERMINAL  :  FILE  TYPE; 

TO  ;  BOOLEAN  : =  TRUE) ; 

SET_ECH0 

(TO  :  BOOLEAN  : =  TRUE) ; 

ECHO 


(TERMINAL  :  FILE  TYPE)  return  BOOLEAN; 
echo  ~  return  boolean; 

MAXIMUMFUNCTIONJCEYS 

(TERMINAL  :  FILEJTYPE)  return  NATURAL; 
MAXIMUM  FUNCTIONJCEYS  return  NATURAL; 

GET 

(TERMINAL  ;  FILE_TYP£; 

ITEM  :  OUt  CHARACTER; 

KEYS  :  OUt  FUNCTION  JCEYJiESCRIPTOR)  ; 
GET 

(ITEM  :  OUt  CHARACTER; 


KEYS  :  out  FUNCTION  JOEY JJESCRIPTOR)  ; 
GET 


(TERMINAL  :  FILETYPE; 

ITEM  :  out 'STRING; 

LAST  :  OUt  NATURAL; 

KEYS  :  OUt  FUNCTION  JCEYDESCRIPTOR)  ; 

GET 

(ITEM  ;  out  STRING; 

LAST  :  out  NATURAL; 

KEYS  .  OUt  FUNCTION  KEY JJESCRIPTOR) ; 
FUNCTION  JCEYCOUNT 

(KEYS  7  FUNCTION  JCEYDESCRIPTOR) 

return  natural; 


FUNCTION  JCEY 
(KEYS 
INDEX 

KEY_IDENTIFIER 
POSITION 

FUNCTION  KEY  NAME 
(TERMINAL 
KEY_IDENTIFIER 
KEY~NAME 
LAST 

FUNCTION  KEY  NAME 
(KEY_IDENTIFIER 
KEYJIAME 
LAST 

DELETE  JTHARACTER 
(TERMINAL  :  FILE  TYPE; 
COUNT  :  POSITIVE  : 
DELETE  CHARACTER 


FUNCTION  KEY  DESCRIPTOR; 

positiveT 

out  POSITIVE; 
out  NATURAL)  ; 

FILEJTYPE; 

POSITIVE; 
out  STRING; 
out  POSITIVE); 

POSITIVE; 
out  STRING; 
out  POSITIVE) ; 


=  t>; 


(COUNT  :  POSITIVE  :=  1) ; 


DELETE  J.  I NE 
(TERMINAL  :  FILEJTYPE; 
COUNT  :  POSITIVE  :=1); 
DELETE  LINE 
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(COUNT  :  POSITIVE  :=  l); 

procedure  erasecharacter 

(TERMINAL  :  FILE  TYPE; 

COUNT  ;  POSITIVE  :=  1); 

procedure  erase  character 

(COUNT  :  POSITIVE  :=  1) ; 

procedure  erase  in  display 

(TERMINAL  :  FILE_TYPE; 

SELECTION  :  SELECT_ENUVERATION) ; 
procedure  erase  in  display 

(SELECTION  :  SELECT_ENUMERATION) ; 
procedure  erase  in  line 

(TERMINAL  :  FILE  TYPE; 

SELECTION  :  SELECT_ENUMERATION) ; 
procedure  erase  in  line 

(SELECTION  :  SELECT_ENUMERATION) ; 

procedure  insertspace 

(TERMINAL  :  FILE_TYPE; 

COUNT  :  POSITIVE  :=  1); 

procedure  insert  space 

(COUNT  :  POSITIVE  :=  t) ; 
procedure  INSERT  LINE 

(TERMINAL  :  FILETYPE; 

COUNT  :  POSITIVE  :=  1); 

procedure  insertline  (count  .  positive  ;=  1); 
function  graphicrendition  support 

(TERMINAL  :  FIL£_TYPE; 

RENDITION  ;  GRAPHIC_RENDITION_ARRAY) 

return  boolean; 

function  graph  i  crend  iti  onsupport 

(RENDITION  :  GRAPHIC_RENDITION_ARRAY) 

return  boolean; 

procedure  select  graphic  rendition 

(TERMINAL  :  FILE  TYPE; 

RENDITION  :  GRAPHICRENDITIONARRAY  := 

DEFAULTGRAPHICRENDITION) ; 

procedure  select  graphic  rendition 

(RENDITION  :  GRAPHIC_RENDITION_ARRAY  := 

default”graphic_rendition) ; 

end  PAGE  TERMINAL; 

package  form  terminal  is 
use  NODEDEFINITIONS; 
use  io  dIfinitions; 

type  AREA  TNTENSITY  is  (NONE,  normal,  HIGH); 
type  AREA  PROTECTION  is  (UNPROTECTED ,  PROTECTED)  ; 
type  AREA  INPUT  is 

(GRAPHIC  CHARACTERS,  NUMERICS, 

AJ.PHABETICS)  ; 

type  afea  value  is 

('  )_FILL,  FILL  *ITH_ZEROES, 
l  C  LL_*ITH_SPACES) ; 

type  F  RM_TYPE  (ROW  :  POSITIVE; 

COLUMN  :  POSITIVE; 

AREAJJUALIFIER_R£QUIRES_SPACE  :  BOOLEAN)  IS  private; 

subtype  printable  character  is  character  range  •  • 
function  maximumfunctionkeys 

(TERMINAL  :  FILETYPE)  return  NATURAL; 
function  maximum  function  keys  return  natural; 
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procedure  DEFINE  QUALIFIED  AREA 

(FORM  .  in  out  FORM  TYPE; 

INTENSITY  :  AREA_ INTENSITY  :=  NORMAL; 

PROTECTION  :  AREA~PROTECTION  ;=  PROTECTED; 

INPUT  :  AREA~INPUT  := 

GRAPH I CCHARACTERS ; 

VALUE  :  AREAVALUE  :=  NO  FILL); 

procedure  remove_area  qualifier 

(FORM  :  in  out  FORM  TYPE)  ; 
procedure  s exposition 

(FORM  ;  in  out  FORM  TYPE; 

POSITION  :  POSITION  TYPE) ; 

procedure  next  qualified  area 

(FORM  :  in  out  FORM  TYPE; 

COUNT  :  POSITIVE  :  =  "i) ; 
procedure  PUT 

(FORM  :  in  OUt  FORM  TYPE; 

ITEM  .  PRINTABLECHARACTER) ; 
procedure  PUT 

(FORM  :  in  out  FORMTYPE; 

ITEM  ;  STRING); 

procedure  erasearea 

(FORM  ;  in  out  FORM  TYPE)  ; 

procedure  eraseform 

(FORM  ;  in  out  FORM  TYPE) ; 
procedure  activate 

(TERMINAL  ;  FILETYPE; 

FORM  :  in  out  FORM  TYPE)  ; 
procedure  GET 

(FORM  :  in  out  FORM  TYPE; 

ITEM  :  out  PRINTABLE  CHARACTER)  ; 
procedure  get 

(FORM  :  in  OUt  FORM  TYPE; 

ITEM  :  OUt  STRING)” 

function  is_form_ipdated 

(FORM  :  FORM  TYPE)  return  BOOLEAN; 

function  terminationkey 

(FORM  ;  FORM  TYPE)  return  NATURAL; 
function  form  size 

(FORM  :  FORM  TYPE)  return  POSITION  TYPE; 

function  terminalsize 

(TERMINAL  :  FILETYPE)  return  POSITION  TYPE; 

function  terminalsize  return  position  type; 
function  areaqualifierrequires  space  - 

(FORM  :  F0RM_TYPE)  return  BOOLEAN;  >> 

function  area  qualifier  requires  space 

(TERMINAL  :  FILE_TYPe7  return  BOOLEAN; 

function  area_qualifier_requires_space  return  boolean; 
private 

type  formjtype  (ROM  :  positive; 

COLUMN  :  POSITIVE; 

AREA_QUALIFIER  REQUIRES  SPACE  :  BOOLEAN)  is 

record 

null;  —  should  b«  dsflnsd  by  lspltasntor 
end  record; 

end  FORM  TERMINAL; 


package  magnetic  tape  is 
use  NODE_DEFINITIONS; 
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use  IO_DEFINITIONS; 
type  TAPE_POSITION  is 

(BEGINNING _OF_TAPE,  PHYSICAL_END_OF  TAPE, 

TAPE_MARk7  OTHER) ; 

subtype  volume_string  is  string  a  . .  a) 

subtype  file  string  is  string  (i  . .  17  ; 

subtype  reel'name  is  string: 

subtype  file  type  is  cais. io_defini' ions. file _type; 

subtype  label_string  is  string  (i...bo:; 

procedure  mount  (tape_drive  :  in  file_tyte; 

TAPENAME:  in  REEL_Ny«E; 

DENSITY:  in  POSITIVE: 

procedure  LOAD_UNLABELED(TAPE_DRrVE:  in  ETYPE; 

DENSITY:  OSITIVE; 

BLOCX_SIZE:  POSITIVE); 

procedure  initializejjnlabeled  (tapedri  .  in  file  type)  ; 
procedure  load_labeled (tape_drive :  in  file  type; 

VOLUME_IDENTIFIER :" in  VOLUME  STRING; 
DENSITY:  in  POSITIVE: 

BLOCK_SIZE :  in  POSITIVE); 

procedure  initialize_labeled(tape_drive:  in  file  type; 

VOLUME_IDENTCFIER :  in 

VOLUMESTRING; 

ACCESSIBILITY:  in  CHARACTER  :  =  '  ’); 
procedure  unload  (tapedrive  :  in  file  type)  ; 
procedure  dismount  (TAPEJJRIVE:  In  file_type)  ; 
function  is_loaded(tape_drive:  in  file_type) 

'return  boolean; 

function  is_mounted(tape_drive:  in  file_type) 
return  boolean  ; 

function  tape  status  (tape_drive  :  in  file  type) 
return  tapeposition; 

procedure  rev i nd  tape  (tape_drive  :  in  file_type): 
procedure  skip  tape  marks  (tapedrive :  in  file  type; 

NUMBER:  in  INTEGER  :=1; 
TAPESTATE :  out  TAPE_POSITION)  ; 

procedure  writetapemark (tapejdrive :  file  type; 

NUMBER:  POSITIVE  :*t: 

TAPE_STATE:  Out  TAPE  POSITION)  ; 

procedure  volume_header(tape_drive:  file  type; 

voluveJidentifier:  VOLUME_STRING; 
ACCESSIBILITY:  CHARACTER  ?=•  •); 

procedure  file_header  (tape_drive  :  file_type; 

FILE_IDENTIFIER:  FILE  STRING; 
EXPIRATION_DATE:  STRING  :=*  99306’; 
ACCESSIBILITY:  CHARACTER  :='  ’) ; 

procedure  end_file_label(tape_drive:  file_type)  ; 
procedure  read_label(tape_drive:  file_typ£; 

label"  out  LABEL  "string); 


end  MAGNETIC  TAPE ; 

package  file_import_export  is 

use  NODE_DEFINITIONS; 

procedure  import  (node  :  node_type; 

HOSTFILENAME  :  STRING); 
procedure  IMPORT  (NAME:  in  namestring; 

HOSTFILENAME:  in  STRING); 

procedure  export  (node  :  node  type; 

HOSTFILENAME  :  STRING). 

Page  3-323 

210 


Pit Ol'O-KD  MIL-TD-f  Als 
•tl  1AM  \RY  108.5 

procedure  export  (make.-  in  najiestring. 

HOSTFILEHANE:  in  STRING) ; 

end  FILE_IHPORT_EXPORT; 

end  cais; 
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Appendix  C 
CAIS  Body 

with  CALENDAR- 
package  body  cais  is 

package  body  nodemanagement  is  separate; 

package  body  attributes  is  separate; 

package  body  access_CONtrol  is  separate: 

package  body  structural_nodes  is  separate; 

package  body  process_comtrol  is  separate; 

package  body  directio  is  separate; 

package  body  sequential  : o  is  separate; 

package  body  text  io  is  separate; 

package  body  iocontrol  is  separate: 

package  body  ^definitions  is  separate; 

package  body  scroll_terminal  is  separate; 

package  body  page_TERMINAL  is  separate; 

package  body  form  terminal  is  separate; 

package  body  magneticjape  is  separate; 

package  body  fileimportexport  is  separate; 

package  body  list  utilities  is  separate; 
end  cais; 

with  calendar; 
separate  (cais) 

package  body  node  hanagement  is 
use  node  definitions  ; 

USe  CALENDAR; 

procedure  open  (node  :  in  out  node  type; 

NAME  :  NAMESTRING; ~ 

INTENT  ;  INTENTION  :=  (1  =>  READ); 

TIME_LIMIT  :  DURATION  ;=  NO  DELAY)  is 

begin 

null;  —  should  b*  dsflntd  by  lsplaaantor 
end  OPEN; 

procedure  open  (node  •.  In  out  node  type-, 
base  ;  NODE  TYPE; 

KEY  :  RELATIONSHIP  KEY; 

RELATION  :  RELATION  NAME  := 

DEFAULT  RELATION; 

INTENT  :  INTENTION  :*  (1  =>  READ); 

TIME  LIMIT  :  DURATION  :=  NO  DELAY)  is 

begin 

null.  -  should  bs  dsflnsd  by  lsplsssntor 
end  0;  n  ; 
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procedure  close  (node  .  in  out  node  type)  is  separate; 

procedure  change_intent 

(no!  :  ;  in  out  node_type; 

INTENT  :  INTENTION; 

TINE_LIMIT  ;  DURATION  :=  N0_DELAY)  is  separate; 

function  is_open(node  ;  node_type)  return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  should  b«  defined  by  lapleaestor 
return  RESULT; 
end  IS  OPEN; 

function  intent_of(node  :  nodetype) 

return  intention  is  separate; 

function  kind(node  :  node  TYPE)  return  node  kind  is  separate: 

function  primary  name  (node  :  node  type) 

return  name  string  is  separate: 

function  PRIMARY  KEY  (NODE  :  NODE  TYPE) 

return  relationship  jcey  is  separate; 

function  primary_relation(node  :  node  type) 
return  relationname  is  separate; 

function  path  key (node  :  N0DE_type) 

return  relationship  jcey  is  separate; 

function  path_relation(node  :  nodetype) 

return  relation  name  is  separate; 

function  base_path(name  :  name  string) 

return  name  string  is  separate; 

function  lastrelation  (name  :  name  string) 
return  relation  name  is  separate; 

function  last j;ey (name  :  name  string) 

return  relationship  jcey  is  separate; 

function  ^OBTAINABLE (NODE  :  NODE  TYPE) 
return  boolean  is  separate; 

function  is_obtainable  (name  :  name  string)  return  boolean  is 
NODE  :  NODE  TYPE; 

RESULT  :  BOOLEAN; 

begin 

OPEN  (NODE.  NAME.  (1  =>  EXISTENCE)); 

RESULT  :=  IS_OBTAINABLE  (NODE); 

CLOSE  (NODE)? 

return  result; 
exception 

when  others  =>  return  FALSE; 
end  IS  OBTAINABLE; 


function  ^obtainable 

(BASE  :  NODETYPE; 

KEY  :  RELATIONSHIP  KEY; 

RELATION  ;  RELATION  NAME  :  =  DEFAULT_RELATION) 

return  boolean  is 
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MODE  :  NODE  TYPE; 

RESULT  :  BOOLEAN; 
begin 

OPEN  (NODE.  BASE,  KEY,  RELATION,  <1  =>  EXISTED  )); 
RESULT  : =  IS_OBTAINABLE  (NODE) ; 

CLOSE  (NODE)T 
return  result; 
exception 

when  others  =>  return  false; 
end  IS  OBTAINABLE; 


function  is_same(nodei  :  node_type; 

NODE2  :  node_type)  return  boolean  is  separate; 

function  issamecnamei  ;  namestring; 

HAKE 2  :  NAME  STRING)  return  BOOLEAN  is 
NODE1 ,  NODE2  :  NODE_TYPE ; 

RESULT  :  BOOLEAN; 

begin 

OPEN  (NODE1.  NAXE1 ,  (1  =>  EXISTENCE)); 

begin 

OPEN  (NODES ,  NAME2,  (1  =>  EXISTENCE) ) : 
exception 

when  others  => 

CLOSE  (NODE1) ; 

raise; 

end; 

RESULT  :=  IS_SAME  (NODE1 ,  NODES); 

CLOSE  (NODE1); 

CLOSE  (N0DE2); 

return  result; 

end  ISSAME; 


procedure  get  parent 

(PARENT  ~  ;  in  OUt  NODE  TYPE; 

NODE  :  NODE  TYPE; 

INTENT  :  INTENTION  :=  (1  =>  READ); 

TIME  LIMIT  :  DURATION  :=  NO  DELAY)  is  Separate; 

procedure  copynode 

(FROM  :  NODE  TYPE; 

TOBASE  :  NODE~TYPE ; 

TOKEY  :  RELATIONSHIP_KEY ; 

TO~RELATION  ;  RELATION  NAME  := 

default_relation)  is  separate; 

procedure  copy_node(from  ;  node_type; 

TO  :  NAME  STRING)  is 

TO_BASE  :  NODE_TYPE ; 
begin 

OPEN  (TOBASE,  BASEPATH  (TO), 

(1  =>  APPEND_RELATIONSHIPS) ) ; 

COPYNODE 

(FROM,  TOBASE.  LAST  KEY  (TO),  LA5T_RELATI0N  (TO)); 
CI  OSE  (T0_Ba5e)  ; 
exception 
when  others  => 

CLOSE  (TO_BASE); 
raise; 

end  copy  node; 
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procedure  copytree 

(FROM  :  N0DE_TYPE; 

TO  BASE  :  NODE’iYPE, 

TOJCEY  :  RELATIONSHIP  KEY; 

TO ’RELATION  :  RELATIONNAME  : = 

DEFAULT_RELATlON)  ia  separate; 

procedure  copy  tree  (from  :  node_type; 

TO  :  NAME  STRING)  ia 

TO  BASE  :  NODE_TYPE ; 
begin 

OPEN  (TO  BASE,  BASE  PATH  (TO). 

(l”=>  APPENDRELATIONSHIPS)); 

COPYTREE 

(FROM,  TOBASE,  LASTKEY  (TO),  LASTRELATION  (TO)); 
CLOSE  (TOBASE) ; 
exception’ 
when  others  => 

CLOSE  (TO_BASE) ; 
raise; 

end  copy  TREE; 


procedure  rename(node  :  N0DE_TYPE; 

HEWBASE  :  NODE  TYPE; 
NEWKEY  :  RELATIONSHIPS; 

NEWRELATION  :  RELATION  NAME  :* 
default_relation)  is  separate; 

procedure  rename  (node  :  node  type; 

NEV  NAME  :  NAME  STRING)  is 
NEW  BASE  :  NODETYPE;’ 
begin 

OPEN  (new  base,  base  PATH  (NEWNAME) . 

(1  =>  APPENDRELATIONSHIPS)) ; 

RENAME 

(NODE.  NEWBASE.  LASTKEY  (NEWNAME) , 

LAST  RELATION  (NEW  NAME) ) ; 

CLOSE  (NEWBASE) ; 
exception 
when  others  => 

CLOSE  (NEWBASE); 
raise; 
end  RENAME; 


procedure  DELETE_NODE(NODE  :  in  out  node_TYPE>  is  separate ; 
procedure  delete_node  (name  :  name  string)  is 

NODE  :  NODE_TYPE~ 
begin 

OPEN  (NODE.  NAME.  (EXCLUSIVE  WRITE.  READ  RELATIONSHIPS)) ; 
DELETE  NODE  (NODE) ; 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 

end  DELETE  NODE; 


procedure  delete_tree (node  :  in  out  node_type)  is  separate; 
procedure  delete_tree(name  :  name  string)  is 

NODE  :  NODE  TYPE;’ 
begin 
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OPEN  (NODE,  NAME,  (EXCLUSIVE JTRITE,  READRELATIONSHIPS) ) ; 
nP'  ETE  TREE  (NODE)  ; 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 

end  DELETE  TREE; 


procedure  link  (node  :  node_type; 

NEW  BASE  :  NODE_TYPE; 

NEW_KEY  :  RELATIONSHIP_KEY ; 

NEW_RELATION  :  RELATI ON_NAME  := 
DEFAULTRELATION)  is~separate; 

procedure  linx(node  ;  node_type  ; 

NEW_NAME~  :  NAME  STRING)  18 
NEW  BASE  :  NODEJTYPE; 
begin 

OPEN  (NEW  BASE,  BASE  PATH  (NEWNAME) , 

(1  =>  APPENDRELATIONSHIPS) ) ; 

LINK  (NODE,  NEWBASE,  LAST  KEY  (NEWNAME) . 

LASTRELATION  (NEWNAME) ) ; 

CLOSE  (NEW~BASE) ; 
exception 
when  others  => 

CLOSE  (NEWBASE) ; 
raise; 
end  LINK; 


procedure  unlink  (base  :  NODE_TYPE; 

KEY  :  RELATIONSHIP_KEY ; 

RELATION  :  RELATI ONNAME  ;= 

default_relation)  is  separate; 

procedure  unlink  (name  :  name  string)  is 
BASE  :  NODETYPE; 
begin 

OPEN  (BASE.  BASEPATH  (NAME). 

(1  =>  WRITE  RELATIONSHIPS)); 

UNLINK  (BASE.  LASTKEY  (NAME).  LASTRELATION  (NAME)); 
CLOSE  (BASE); 
exception 
when  others  -> 

CLOSE  (BASE) ; 
raise; 
end  UNLINK; 


procedure  iterate 
(ITERATOR 
NODE 
KIND 
KEY 


OUt  NODE_ITERATOR; 
NODE_TYPE~ 

NODEKIND; 

RELATIONSHIP  KEY_PATTERN  := 


RELATION  :  RELATI 0N_NAME  PATTERN  := 

DEF AULTRELATI ON ; 

PRIMARY_ONLY  :  BOOLEAN  :=  TRUE)  is  separate; 


procedure  iterate 

(ITERATOR  :  out  NODE_ITERATOR ; 

NAME  :  NAME_STRING ; 

KIND  :  N0DE~KIND; 

KEY  :  RELATIONSHIP  KEY  PATTERN  := 
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RELATION  :  RELATION  NAMEPATTERN  := 
DEFAULTRELATION; 

PRIMARY_ONLY  :  BOOLEAN  :=  TRUE)  is 
NODE  :  NODEJTYPE; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ  RELATIONSHIPS)); 
ITERATE  (ITERATOR.  NODE.  KIND.  KEY.  RELATION. 

PRIMARYQNLY) ; 

CLOSE  (NODE) ;~ 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  ITERATE; 


function  more  (iterator  .  nodeiterator)  return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  should  bs  dsflnsd  by  lsplsssntor 
return  result; 
end  MORE; 

procedure  get_next 

(ITERATOR  ;  in  out  NODE_ ITERATOR; 

NEXT  NODE  ;  in  out  NODEJTYPE; 

INTENT  :  INTENTION  :="  (1  =>  EXISTENCE); 

TIME  LIMIT  :  DURATION  :=  NO  DELAY) 

is 

begin 

null;  --  should  bs  dsflnsd  by  lsplsssntor 
end  get  next; 

procedure  set_current_node (node  :  node  type)  is  separate; 
procedure  set_current_node(name  :  name  string)  is 

NODE  ;  NODE  TYPE; 
begin 

OPEN  (NODE.  NAME.  (1  =>  EXISTENCE)); 

SET_CURRENT_NODE  (NODE) ; 
exception 
when  others  *> 

CLOSE  (NODE); 
raise: 

end  SET  CURRENT  NODE; 


procedure  get_current_node  (node  :  in  out  node jtype  ; 

INTENT-  ;  in":  INTENTION  ;=  (1  =>  EXISTENCE); 
TIME  LIMIT  :  in  DURATION  :  =  no  delay)  is  separate; 
end  node  management  ; 

separate  (cais) 
package  body  attributes  is 
use  node_definitions; 
use  node'management; 

use  LIST_UTILITIES; 
procedure  create  node  attribute 

(NODE  ~  NODE  TYPE; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST  TYPeF  is  separate; 
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procedure  create_node_attribute 

(NAME  ~  NAJffiSTRING; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST  TYPE!  is 
NODE  :  NODE_TYPE; 
begin 

OPEN  (NODE,  NAME,  (1  =>  APPENDRELATIONSHIPS) ) ; 
CREATE  J)ODE_ATTR I BUTE  (NODE.  ATTRIBUTE.  VALUE); 
CLOSE  (NODE)”; 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  CREATE  NODE  ATTRIBUTE; 


procedure  create  path_ attribute 
(BASE  ~  NODEJIYPE; 

KEY  :  RELATIONSHIPJCEY; 

RELATION  :  RELATION  NAME  := 
DEFAULT_R£LATION; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST_TYPE)  is  separate; 

procedure  createpathattribute 

(NAME  ~  NAJffi  STRING; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST  TYPE)"  is 
BASE  :  NODE  TYPE; 
begin 

OPEN  (BASE.  BASE  PATH  (NAME) . 

(1  =>  WRITERELATIONSHIPS)) ; 

CREATE  PATH  ATTRIBUTE 

(BASE.  LASTJCEY  (NAME) .  LAST  RELATION  (NAME) . 
ATTRIBUTE.  VALUE); 

CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (BASE) ; 
raise; 

end  CREATE  PATH  ATTRIBUTE; 


procedure  delete  nooe  attribute 

(NODE  ~  NODEJTYPE; 

ATTRIBUTE  :  attribute_name)  is  separate; 

procedure  delete  node  attribute 

(NAME  :  NAME_STRINO; 

ATTRIBUTE  :  ATTRIBUTE  NAME)  is 
NODE  :  NODE  TYPE; 
begin 

OPEN  (NODE.  NAME.  (1  =>  WRITEATTRIBUTES) ) ; 
DELETENODE  ATTRIBUTE  (NODE,  ATTRIBUTE); 

CLOSE  (NODE); 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 

end  DELETE_NODE_ATTRIBUTE ; 


procedure  DELETE  PATH  attribute 
(BASE  “  NODETYPE; 

KEY  :  RELATIONSHIPJCEY; 
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RELATION  :  RELATION  NAME  := 

DEFAULT  RELATION; 

ATTRIBUTE  ATTRIBUTENAME)  is  Separate; 
procedure  delete_path_attribute 

(NAME  T  NAMESTRING; 

ATTRIBUTE  :  ATTRIBUTE_NAME)  is 
BASE  :  NODE_TYPE; 
begin 

OPEN  (BASE,  BASE  PATH  (NAME). 

(1  =>  WRITE_RELATIONSHIPS) ) ; 

DELETE  PATH  ATTRIBUTE 

(BASE.  LAST__KEY  (NAME).  LAST_R£LATION  (NAME). 
ATTRIBUTE) 7 
CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (BASE); 
raise; 

end  DELETE  PATH  ATTRIBUTE; 


procedure  set_node_attribute (node  :  node  type; 

ATTRIBUTE  :  ATTRIBUTENAME; 

value  •  listtype)  is  separate; 

procedure  SETN0DEATTRI8UTE  (NAME  :  NAME  STRING; 

ATTRIBUTE  :  ATTR IBUTE_NAME ; 

VALUE  :  LIST_TYPE)  is 

NODE  :  NODE  TYPE; 
begin 

OPEN  (NODE.  NAME.  (1  s>  WRITE  ATTRIBUTES)); 

SET  NODE  ATTRIBUTE  (NODE.  ATTRIBUTE.  VALUE); 

CLOSE  (NODE); 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 

end  SET  NODE  ATTRIBUTE; 


procedure  set  path  attribute 
(BASE  :  NODE  TYPE; 

KEY  :  RELATIONSHIPS; 

RELATION  :  RELATION  NAME  :* 

DEFAULT_RELATION ; 

ATTRIBUTE  :  ATTRIBUTENAME ; 
value  :  LIST  TYPE)  is  separate; 

procedure  set  path  attribute  (name  :  name  string; 
ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  LIST_TYPE)  is 

BASE  :  NODE_TYPE; 
begin 

OPEN  (BASE.  BASE  PATH  (NAME). 

(1  =>  WRITERELATIONSHIPS) ) ; 

SET  PATH  ATTRIBUTE 

(BASE?  LAST_KEY  (NAME) ,  LAST_RELATION  (NAME) . 
ATTRIBUTE. ~VALUE) ; 

CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (BASE); 
raise; 

end  SET  PATH  ATTRIBUTE; 
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procedure  get_node_attribute 

(NODE  "  '  NODE_TYPE; 

ATTRIBUTE  :  ATTRIBUTE_NAME ; 

value  :  in  out  list  type)  is  separate; 
procedure  get  node  attribute 

(NAME  ~  :  NAMESTRING; 

ATTRIBUTE  :  ATTRIBUTE_NAME ; 

VALUE  :  in  OUt  LIST  TYPE)  is 
NODE  ;  NODE_TYPE ; 
begin 

OPEN  (NODE.  NAME,  (1  =>  READRELATIONSHIPS) ) ; 
GET_NODE_ATTR I BUTE  (NODE.  ATTRIBUTE,  VALUE); 

CLOSE  (NODE) ; 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 

end  GET_NODE_ ATTRIBUTE; 


procedure  get  path  attribute 

(BASE  :  NODE  TYPE; 

KEY  :  RELATIONSHIP  KEY: 

RELATION  :  RELATION  NAME  := 

DEFAULTRELATION; 

ATTRIBUTE  :  ATTRIBUTE  NAME; 

VALUE  :  in  out  list  type)  is  separate; 

procedure  GET  PATH  ATTRIBUTE 

(NAME  :  NAMESTRING; 

ATTRIBUTE  :  ATTR I BUTE_ NAME ; 

VALUE  :  in  out  LIST  TYPE)  is 
BASE  :  NODE  TYPE; 
begin 

OPEN  (BASE.  BASEPATH  (NAME).  (1  =>  READRELATIONSHIPS) ) ; 
GETPATHATTRIBUTE 

(BASE.  LASTKEY  (NAME).  LAST  RELATION  (NAME). 
ATTRIBUTE.  VALUE) ; 

CLOSE  (BASE) ; 
exception 
when  others  -> 

CLOSE  (BASE) ; 

raise; 

end  GET  PATH  ATTRIBUTE; 


procedure  node_attribute_iterate 

(ITERATOR  :  OUt  ATTRIBUTE  ITERATOR; 

NODE  :  NODE_TYPE ; 

PATTERN  :  ATTRI8UTE_PATTERN  :=  ’*")  is  Separate; 

procedure  node_attribute_iterate 

(ITERATOR  :  out  ATTRIBUTE  ITERATOR; 

NAVE  :  NAME  STRING; 

PAT  ERN  :  ATTRIBUTE  PATTERN  :=  ■*•)  is 
NODE  :  NOT  :_TYPE; 
begin 

OPEN  (NODf  .  NAME,  (1  =>  READ_ ATTRIBUTES) ) ; 

NODE_ATTR  1 UUTE_ITERATE  (ITERATOR.  NODE,  PATTERN); 

CLOSE  (NODE) ; 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise; 
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end  NODE  ATTRIBUTE  ITERATE; 


procedure  path_attribute_iterate 

(ITERATOR*  :  in  OUt~ATTRIBUTE_ITERAT0R; 

BASE  :  NODE_TYPE; 

KEY  :  RELATIONSHIPKEY; 

RELATION  ;  RELATION  NAME 
DEFAULT_ RELATION; 

PATTERN  .  ATTRIBUTEPATTERN  ;=  *•*)  is  separate: 

procedure  path_attr i bute_ i terate 

(ITERATOR  :  in  OUt-ATTRI8UTE_ITERATOR ; 

NAME  :  NAMESTRING; 

PATTERN  :  ATTRIBUTE_PATTERN  :=  ***)  is 
BASE  :  NODE  TYPE; 
begin 

OPEN  (BASE.  BASEPATH  (NAME). 

(1  =>  WRITE  RELATIONSHIPS) ) ; 

PATHATTRIBUTEITERATE 

(ITERATOR.  BASE,  LAST  JOEY  (NAME) . 

LASTRELATION  (NAME) 7  PATTERN) ; 

CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (BASE) ; 
raise; 

end  PATH  ATTRIBUTE  ITERATE; 


function  MORE  (ITERATOR  :  ATTRIBUTE_ITERATOR) 
return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  shoals  bs  defined  by  lsplesentor 
return  result; 
end  MORE; 

procedure  getnext (iterator  :  in  out  attr i bute_iterator ; 
ATTRIBUTE  :  out  ATTRIBUTE  NAME; 

VALUE  :  in  out  LIST_TYPE) 

is 

begin 

null;  —  should  be  defined  by  lsplsasntor 
end  GET  NEXT; 

end  ATTRIBUTES; 

separate  (CAIS) 

package  body  access_control  is 
use  NODE_DEFINITI ONS ; 
use  NODE*MANAGEMENT; 

procedure  set_access  control 

(NODE  ~  :  NODE  TYPE; 

R0LE_N0DE  :  NODEJTYPE ; 

grant  :  grant  value)  is  separate; 

procedure  set_access_coxtrol 
(NAME  ~  :  NAME  STRING; 

ROLENAME  :  NAME “STRING; 

GRANT  :  GRANT  VALUE)  is 
NODE.  ROLE  NODE  :  NODE  TYPE; 
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begin 

OPEN  (NODE,  NAME.  (1  =>  CONTROL)); 

OPEN  (ROL£_NODE,  ROLENAME ,  (1  =>  EXISTENCE)); 
SET_ACCESS~CONTROL  (NODE,  ROLE_NODE ,  GRANT); 
CLOSE  (NODE) ; 

CLOSE  (ROLE_NODE) ; 
exception 
when  other  => 

CLOSE  (NODE) ; 

CLOSE  (ROL£_NODE); 
raise; 

end  set  access  control; 


function  IS  GRANTED  (OBJECT  NODE  :  NODE  TYPE; 

ACCESS_RIGHT  :  NAME_STRING) 
return  boolean  is  separate; 

function  IS_GRANTED  (OBJECT  NAME  :  NAME  STRING; 

ACCESSRIGHT  :  NAMESTRING) 
return  boolean  is 
OBJECTNODE  :  NODE  TYPE; 

RESULT  :  BOOLEAN ; 

begin 

OPEN  (OBJECTNODE,  OBJECTNAME. 

(1  =>  READRELATIONSHIPS) ) ; 

RESULT  : =  ISGRANTED  (OBJECTNODE .  ACCESS  RIGHT) ; 
CLOSE  (OBJECTNODE) ; 
return  result; 
exception 
when  others  => 

CLOSE  (OBJECTNODE) ; 
raise: 

end  is  granted; 


procedure  adopt  (role  node  :  node  type)  is  separate; 

ROLE  KEY  .  RELATIONSHIP  KEY  :=  (-ATEST_KEY) 

is  separate; 

procedure  unadopt (role  key  :  relat i o nsh i p_key)  is  separate; 
end  ACCESS  CONTROL; 

separate  (CAIS) 

package  body  structural  nodes  is 
use  node  definitions; 

use  NODEMANAGEMENT; 

procedure  create_node 

(NODE  "  :  in  out  NODETYPE; 

BASE  :  N0DE_TYPE ; 

KEY  :  RELATIONSHIPKEY  := 

LATEST_KEY; 

RELATION  :  RELATIONNAME  := 

DEFAULT_RELATION; 

ATTRIBUTES  :  LIST  TYPE  ;=  EMPTY_LIST ; 

ACCESS_CONTROL  :  LIST_TYPE  :=  EMPTY  LIST; 

level  ~  :  list'type  :=  empty'list)  is  separate; 

procedure  create _node 

(NODE  ;  in  out  NODE  TYPE; 

NAME  :  NAME  STRING  f 

ATTRIBUTES  :  LIST~TYPE  :=  EMPTY_LIST ; 

ACCESS _C0NTR0L  :  LIST~TYPE  :=  EMPTY_LIST ; 

LEVEL  “  :  LISt’tYPE  :=  EMPTY_LIST)  is 
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BASE  :  NODE_TYPE; 
begin 

OPEN  (BASE,  BASEPATH  (NAME). 

(1  =>  APPEND_R£LATIONSHIPS) ) ; 

CREATE  NODE 

(NODE.  BASE,  LAST  KEY  (NAME) .  LAST_RELATIOK  (NAME) . 
ATTRIBUTES.  ACCESS  CONTROL,  LEVEL)"; 

CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (NODE); 

CLOSE  (BASE); 
raise; 

end  CREATE  NODE; 


procedure  create  node 

(BASE  ~  :  NODETYPE; 

KEY  :  RELATIONSHIP_KEY  := 

LATEST  JCEY; 

RELATION  :  RELATIONNAME  := 

DEFAULT  RELATION; 

ATTRIBUTES  :  LIST_TYPE  :=  EMPTY  LIST; 

ACCESS  CONTROL  ;  LIffT~TYPE  ;=  EMPTY~LIST; 

LEVEL  “  :  LIST~TYPE  :=  EMPTY~LIST)  is 

NODE  :  NODETYPE; 
begin 
CREATENODE 

(NODE.  KEY.  RELATION.  ATTRIBUTES,  ACCESS  CONTROL. 
LEVEL) ; 

CLOSE  (NODE) ; 
end  CREATE  NODE; 


procedure  createjwde 

(NAME  ~  :  NAMESTRING; 

ATTRIBUTES  :  LIST  TYPE  :=  EMPTY_LIST ; 

ACCESSCONTROL  :  LIST~TYPE  :=  EMPTY~LIST; 

LEVEL  :  LISTJTYPE  :=  EMPTY~LIST)  is 

NODE  :  NODETYPE; 
begin 
CREATENODE 

(NODE,  NAME,  ATTRIBUTES.  ACCESSCONTROL .  LEVEL); 
CLOSE  (NODE) ; 
end  CREATE  NODE ; 
end  STRUCTURALJfODES ; 

separate  (cais) 

package  body  process  control  is 
use  NODEDEFINITIONS; 
use  PROCESS_DEFINITIONS ; 
use  NODEMANAGEMENT; 
use  LISTJJTILITIES; 

procedure  spawnprocess 

(NODE 
FILE_NODE 
INPUT_PARAMETERS 
KEY 

RELATION 

ACCESS  CONTROL 
LEVEL  “ 

ATTRIBUTES 


:  in  out  NODE  TYPE; 

:  NODE_TYPE ; 

:  PARAMETERLIST 
:  RELATIONSHIP_KEY  := 
LATEST_KEY ; 

:  RELATIONNAME  = 
DEFAULT_RELATION ; 

:  LIST_TYPE  :=  E:'PTY_LIST; 
:  LISTJTYPE  :=  EMPTy"lIST; 
:  LIST "TYPE  :=  EMPTY~LIST; 
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INPUT_FILE 
OUTPUT_FIL£ 
ERROR  FILE 


:  NAMESTRINC  :  = 
CURR£NT_INFUT ; 

:  NAME_STRING  := 
CURRENT J1UTPUT ; 
:  NAME_STRING  := 
CURR£NT_ERROR ; 


ENVIRONMENT_NODE  :  NAME_STRING  := 

current_node)  is  separate; 

procedure  await_process_completion 

(NODE  :  NODE_TYPE ; 

TIMEJ.IKIT  ;  DURATION  :=  DURATION ’LAST) 

is  separate; 

procedure  await_process_completion 

(NODE  ~  :  N0DE_TYPE ; 

RE  5ULTS_RETURNED  :  in  out  RESULTS  LIST; 

STATUS  :  out  PROCESS  STATUS ; 

TIME_LIMIT  :  DURATION  := 

DURATION 'LAST)  is 

begin 

AWAITPROCESSCOKPLETION  (NODE,  TINE  LINIT) ; 
OETRESULTS  (NODE,  RESULTS  RETURNED)” 

STATUS  ;=  STATE  OF_PROCESS~(NODE) ; 
end  AWAIT  PROCESSCOMPLETION; 


procedure  invokeprocess 
(NODE 
FILENODE 
RESULTSRETURNED 
STATUS  ~ 
INPUTPARANETERS 
KEY 

RELATION 

ACCESSCONTROL 
LEVEL 
ATTRIBUTES 
INPUTFILE 

OUTPUTFILE 

ERRORFILE 

ENVIRONKENTNODE 

TIKE  LIMIT 


procedure  create  job 
(FILE_NODE  “ 

INPUT  PARAMETERS 
KEY 

ACCESS_CONTROL 

LEVEL 

ATTRIBUTES 

INPUT_FILE 

OUTPUT_FILE 

ERROR  FILE 


in  out  node  TYPE; 

NODE  TYPE; 

in  out  RESULTSJ.IST; 

OUt  PROCESS  STATUS; 
PARAMETER  LIST  :=  *•; 
RELATIONSHIP  KEY  := 

LATEST  KEY; 

:  RELATION^ NAME  := 

DEF  AULT_RELAT I C  N ; 

:  LIST_TYPE  :=  EMPTY_LIST; 

:  LIST_TYPE  .=  EMPTYLIST; 

:  LIST_TYPE  :=  EMPTY~LIST ; 

:  NAME~STRING  ;= 

CURRENT  INPUT; 

:  NAMESTRING  := 

CURRENT  OUTPUT; 

:  NAME  STRING  :  = 
CURRENT_ERROR; 

:  NAMESTRING  := 

CURRENT_NODE ; 

:  DURATION  := 

duration ’last)  is  separate: 


NODE_TYPE ; 
PARAMETER_LIST ; 
RELATIONSHIP  KEY  := 
LATEST_KEY ; 

LIST_TYPE  ;=  EKPTY_LIST; 
LIST_TYPE  :=  EMPTY_LIST; 
LIST_TYPE  :=  EMPTY~LIST; 
NAME~STRING  := 

CURRENT_ INPUT, 
NAMESTRING  := 
CURRENT_OUTPUT ; 
NAME_STRING  := 
CURRENTERROR ; 
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ENVIROHMENT_NODE  :  NAMESTRING  :=  CURREWT_USER) 

is  separate; 

procedure  append_results  (results  :  results_string) 

iaaeparate ; 

procedure  write_results (results  :  results_strimc)  is  separate: 

procedure  get_results (node  :  node_type; 

results  .  in  out  results_list)  is  separate; 

procedure  get_results  (mode  :  node_type; 

RESULTS  :  in  out  RESULTS  "list; 

STATUS  :  out  PROCESS_STATUS)  is 

begin 

GETRESULTS  (MODE,  RESULTS); 

STATUS  :=  STATEOFPROCESS  (MODE); 

end  get  results  r 


procedure  getresults  (name  :  mame  strimg; 

RESULTS  :  in  out  RESULTS_LIST; 
STATUS  :  Out  PROCESSSTATUS)  is 
NODE  :  MODE  TYPE; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ  ATTRIBUTES)); 
GETRESULTS  (NODE.  RESULTS) ;~ 

STATUS  ; s  STATE  OF  PROCESS  (NODE) ; 

CLOSE  (NODE); 
exception 
when  others  => 

CLOSE  (NODE); 
ruse; 

end  GET  RESULTS; 


procedure  get  results  (name  :  name  string; 

RESULTS  :  in  Out  RESULTS_LIST)  is 
NODE  :  NODETYPE; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READATTRIBUTES)) ; 
GETRESULTS  (NODE.  RESULTS);" 

CLOSE  (NODE); 

exception 
when  others  => 

CLOSE  (NODE); 

raise; 

end  GET  RESULTS; 


procedure  get  parameters 

(PARAMETERS  ;  in  out  PARAMETER  LIST)  is  separate; 

procedure  abort_process  (node  :  node_type; 

rIsults  :  results  string!  is  separate; 

procedure  abort  process (name  :  name_string; 

RESULTS  :  RESULTS_STRING)  is 
NODE  :  NODE_TYPE; 
begin 

OPEN  (NODE.  NAME,  (READ_RELATIONSHIPS , WRITE_CONTENTS , WRITE__ATTRIBUTES) ) 
ABORTPROCESS  (NODE,  REiuLTS) ; 

CLOSE” (NODE) ; 
exception 
when  others  -> 
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CLOSE  (NODE); 

raise; 

end  ABORT  PROCESS; 


procedure  abort_process  (node  :  node_type)  is 

begin 

ABORT_PROCESS  (NODE.  "ABORTED"); 
end  ABORT  PROCESS; 


procedure  abortprocess  (name  :  name  string)  is 

NODE  :  NODE_TYPEl 
begin 

OPEN  (NODE.  NAME,  READ_RELATIONSHIPS . NRITECONTENTS . WRITE  ATTRIBUTES) ) ; 
ABORTPROCESS  (NODE.  "ABORTED*) ; 

CLOSE- (NODE) ; 
exception 
when  others  => 

CLOSE  (NODE) ; 
raise: 

end  ABORT  PROCESS; 


procedure  suspendprocess (node  :  node_type)  is  separate; 

procedure  suspend  process  (name  :  name  string)  is 
NODE  :  NODE  TYPE;  “ 
begin 

OPEN  (NODE.  NAME.  READRELATIQNSHIPS , NRITECONTENTS . NRITEATTRIBUTES) ) ; 
SUSPENDPROCESS  (NODE) ; 

CLOSE  (NODE); 
exception 
when  others  => 

CLOSE  (NODE)  ; 
raise; 

end  SUSPEND  PROCESS; 


procedure  resumeprocess (node  :  nodetype)  is  separate; 

procedure  resumeprocess  (name  :  name  string)  is 
NODE  :  NODE  TYPE; 
begin 

OPEN  (NODE,  NAME,  READ_R£LATIONSHIPS , WRITE_ATTRIBUTES , WRITECONTENTS) ) ; 
RESUMEPROCESS  (NODE) ;~ 

close  Inode) ; 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  RESUME  PROCESS; 


function  status__of_process  (node  :  nodetype) 
return  process  status  is  separate; 


function  status_of_process(name  :  name  string) 
return  process  status  is 

NODE  :  N0DE_TYPE ; 

RESUIT  :  PROCESS _STATUS; 

begin 

OPEN  (NODE.  NAME.  (1  =>  READ_ATTRIBUTES) ) ; 
RESUIT  :=  STATE  OF  FTOCESS  (NODE); 


Page  3-339 


265 


PROPOSED  MIL-STD-CAIS 
31  JAM  ARY  198.3 


CLOSE  (NODE) ; 

return  result; 
exception 
when  others  => 

CLOSE  (NODE) ; 

raise; 

end  status  of  process; 


function  handles  open  (node 


node  type)  return  natural 

is  separate; 


function  handles_open(name  :  namestring)  return  natural  is 

NODE  :  NODEJTYPE; 

RESULT  :  NATURAL; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ  ATTRIBUTES)); 

RESULT  :=  HANDLES  OPEN  (NODE)"; 

CLOSE  (NODE) ; 
return  RESULT: 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  HANDLES  OPEN; 


function  io_units(node  :  node_type)  return  natural  is  separate; 
function  io  units  (name  :  name  string)  return  natural  is 

NODE  :  NODE  TYPE; 

RESULT  :  NATURAL; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ  ATTRIBUTES)); 

RESULT  :=  10  UNITS  (NODE); 

CLOSE  (NODE) 7 
return  RESULT; 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  10  UNITS; 


function  startjtme  (node  ;  node_type) 
return  time  is  separate; 

function  start_time(name  :  name  string) 
return  time  is 

NODE  :  N0DE_TYPE; 

RESULT  :  TIME? 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ_ ATTRIBUTES) ) ; 
RESULT  :=  START  TIME  (NODE) ;” 

CLOSE  (NODE) ; 

return  result; 
exception 
when  others  => 

CLOSE  (NODE) ; 

raise; 

end  START  TIME; 


function  finish_time(node  :  node_type) 
return  TIME  is  separate; 
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function  finish_time (name  :  name  string) 
return  time  is 

NODE  :  NODE_TYP£; 

RESULT  :  TIME? 
begin 

OPEN  (NODE.  NAME,  (1  =>  R£AD_ATTRIBUTES) ) ; 
RESULT  :=  FINISH_TIME  (NODE)T 
CLOSE  (NODE) ; 

return  result; 
exception 
when  others  => 

CLOSE  (NODE); 

raise; 

end  FINISH  TIME; 


function  MACHINE _TIME  (NODE  :  NODE  TYPE)  return  DURATION 

is  separate; 

function  machine  time  (name  :  name  string)  return  duration  is 

NODE  :  NODE  TYPE; 

RESULT  :  DURATION; 
begin 

OPEN  (NODE.  NAME.  (1  =>  READ_ATTRIBtTTES) )  : 

RESULT  :=  MACHINE  TIME  (NODE)"; 

CLOSE  (NODE) ; 
return  result; 
exception 
when  others  => 

CLOSE  (NODE); 
raise; 

end  MACHINE  TIME; 


end  process  control; 

separate  (cais) 
package  body  iocontrol  is 
Use  NODEJ5EFINITIONS; 

use  node'management; 
use  IODEFINITIONS; 
use  LIST_UTILITIES ; 

procedure  opem_file_node (file  :  file_type; 

NODE  :  in  out  NODE_TYPE ; 

INTENT  :  INTENTION; 

TIME_LIMTT  :  DURATION  :=  NO_DELAY) 

is  separate. 

procedure  synchronize  (file  :  file  type)  is  separate; 

procedure  set_log(file  :  file  type; 

log_file  ;  file_type)  is  separate; 

procedure  clear_log (FILE  :  file  type)  is  separate; 

function  logging(FILE  :  file  type)  return  boolean  is  separate; 

function  get_log(file  :  file  type)  return  file  type  is  separate; 

function  number_of_elements (file  :  file  type)  return  natural 

is 

RESULT  :  NATURAL; 
begin 
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—  should  6*  defined  by  laplaaantor ; 
return  result; 
end  MUMBER_OF_ELEMENTS; 

procedure  set_prompt (terminal  :  filejtype; 

prompt  :  string)  is  separate; 

function  CET  PROMPT (TERMINAL  :  FILEJTYPE)  return  STRING 

is  separate; 

function  i ntercepted_characters  (term i nal  :  filejtype) 
return  characterarray  is  separate; 

procedure  enable_function_keys (terminal  :  file_type; 

ENABLE  :  BOOLEAN) 

is  separate; 

function  function jceys  enabled  (terminal  ;  file_type) 

return  BOOLEAN  is  separate; 

procedure  couple 

(QUEUE  BASE  :  NODE  TYPE; 

QUEUE  JCEY  :  RELATIONSHIP  KEY  :  = 

LATESTKEY; 

QUEUE  RELATION  :  RELATION  NAME  := 

DEF  AULT_RELATI ON ; 

FILENODE  ;  NODE  TYPE; 

FORM  :  LISTJTYPE  :=  EMPTYLIST; 

ATTRIBUTES  :  LIST_TYPE;  —  Intentionally 

—  not 

—  defaulted 

ACCESS  CONTROL  :  LIST  TYPE  :*  EMPTY  LIST; 

LEVEL  "  :  LISTJTYPE  :=  EMPTY~LIST)  is  separate; 

procedure  couple 

(QUEUE  NAME  :  NAMESTRING; 

FILENODE  :  NODE  TYPE; 

FORM  :  LISTJTYPE  :=  EMPTY  LIST; 

ATTRIBUTES  :  LISTJTYPE; 

ACCESS_CONTROL  ;  LISTJTYPE  :  =  EMPTYLIST; 

LEVEL  ~  ;  LISTJTYPE  :=  EMPTY”LIST)  5 

BASE  ;  NODE  TYPE; 
begin 

OPEN  (BASE.  BASEPATH  (QUEUE JtAME) , 

(I  =>  APPENDRELATIONSHIPS) ) ; 

COUPLE 

(BASE.  LASTJCEY  (QUEUE  NAME) . 

LASTRELATION  (QUEUE_NAME) ,  FILE_NODE.  FORM. 

ATTRIBUTES.  ACCESS_CONTROL .  LEVEL); 

CLOSE  (BASE) ; 
exception 
when  others  => 

CLOSE  (BASE) ; 
raise; 

end  couple; 


procedure  couple 

(QUEUE  BASE  .  NODE  TYPE; 

QUEUE~KEY  :  RELATIONSHIP  KEY  := 

LATESTKEY; 

QUEUE_R£LATI ON  :  RELATI0N_NAME  :  = 

DEF  AULT_RELATI ON ; 
FILE  NAME  :  NAME  STRING; 
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form  :  LIST_TYPE  :=  EMPTY_LIST; 

ATTRIBUTES  :  LIST~TYPE; 

ACCESS_COMTROL  :  LISTjrYPE  :=  EMPTY  LIST; 

LEVEL  :  LIST_TYPE  ;=  EMPTY~LIST)  is 

FILE_MODE  :  NODE_TYPE ; 
begin 

OPEM  (FILE_NODE,  FILE  NAME.  (READ  ATTRIBUTES.  READ  CONTENTS)); 
COUPLE 

(QUEUEBASE.  QUEUE_KEY,  QUEUE_RELATI ON ,  FILE  NODE. 

FORM ,  ATTRIBUTES , ~ ACCESS  CONTROL .  LEVEL) ; 

CLOSE  (FILE_NODE) ; 
exception 
when  others  => 

CLOSE  (FILENODE); 
raise; 

end  couple; 


procedure  couple 

(QUEUENAME  :  NAMESTRING; 

FILENAME  ;  NAME  STRING; 

FORM  :  LISTJTYPE  :=  EMPTY  LIST; 

ATTRIBUTES  :  LIST  TYPE; 

ACCESSCONTROL  :  LISTJTYPE  :=  EMPTY  LIST; 

LEVEL  :  LIST~ TYPE  ;=  EKPTy'lIET)  is 

FILENODE  :  NODE  TYPE; 

QUEUEBASE  :  NODE  TYPE; 
begin 

OPEN  (QUEUEBASE,  BASEPATH  (QUEUENAME) , 

(1  =>-APPEND_RELATIONSHIPS)>; 

OPEN  (FILENODE.  FILE  NAME.  (READ  ATTRIBUTES,  READ  CONTENTS)); 
COUPLE 

(QUEUEBASE.  LASTKEY  (QUEUENAXE) . 

LAST_RELATI ON  (QUEUENAME) . “FILE  NODE.  FORM. 

ATTRIBUTES.  ACCESS  CONTROL.  LEVEL); 

CLOSE  (QUEUEBASE) ; 

CLOSE  (FILENODE) ; 
exception 
when  others  => 

CLOSE  (QUEUEBASE) ; 

CLOSE  (FILE_NODE); 
raise; 

end  couple; 
end  10  control; 


separate  (cais) 
package  body  directjio  is 
use  NODE_DEFINITIONS; 
use  IO_DEFINITIONS ; 

Use  NODEMANAGEMENT; 


—  Fll*  ssnAgastnt 


procedure  CREATE  (FILE  :  in  out  FILE  TYPE; 

BASE  :  NODE_TYPE; 

KEY  ;  RELATIONSHIP  KEY  := 

LATEST  KEY; 

RELATION  :  RELATIONNAME  := 

DEFAULT  RELATION; 

MODE  :  FILE_MODE  := 
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INOUT  FILE; 

FORM  :  LIST  TYPE  := 

EMPTY  LIST; 

ATTRIBUTES  :  LIST  TYPE  := 

EMPTY  LIST; 

ACCESSCONTROL  :  LIST_TYPE  ;=  EMPTYLIST; 

LEVEL  "  :  LIST~TYPE  :=  EMPTY_LIST) 

is 

begin 

null;  —  should  bs  dsfinsd  by  laplsstntor 
end  CREATE; 

procedure  create  (file  :  in  out  file_type; 

NAME  :  NAMESTRING; 

MODE  :  FILE~MODE  := 

INOUT_FILE; 

FORM  :  LIST  TYPE  := 

EMPTY_LIST; 

ATTRIBUTES  :  LIST  TYPE  ;= 

EMPTY_LIST; 

ACCESSCONTROL  :  LIST_TYPE  :=  EMPTY_LIST; 

LEVEL  :  LISTJTYPE  ;=  EMPTY~LIST)  is 

BASE  ;  NODETYPE; 
begin 

OPEN  (BASE.  BASE  PATH  (NAME). 

(1  =>  APPENDRELATIONSHIPS)); 

CREATE  (FILE.  BASE.  LASTKEY  (NAME), 

LASTRELATION  (NAME) .  MODE.  FORM.  ATTRIBUTES. 
ACCESSCONTROL.  LEVEL); 

CLOSE  (BASE)"; 
exception 
when  others  => 

CLOSE  (FILE); 

CLOSE  (BASE); 
raise; 
end  CREATE; 


procedure  open  (file  ;  in  out  file_type; 

NODE  :  NODE  TYPE; 

MODE  ;  FILEMODE) 

is 

begin 

null;  —  should  bs  dsfmsd  by  lsplessntor 
end  open; 

procedure  open  (file  :  in  out  file_type; 

NAME  :  NAME  STRING; 

MODE  :  FILE~MODE)  is 
NODE  :  NODE  TYPE; 
begin 

case  mode  is 

when  in  file  =>  open  (node,  name, 

(1  =>  READCONTENTS)) ; 
when  OUT  FILE  =>  OPEN  (NODE,  NAME. 

(1  =>  WRITE_CONTENTS) ) ; 
when  INOUT  FILE  =>  OPEN  (NODE,  NAME, 

(READ_CONTENTS .  WRITE_CONTENTS) ) ; 

when  append_file  =>  raise  use_error; 

end  case; 

OPEN  (FILE,  NODE.  MODE); 

CLOSE  (NODE) ; 
exception 
when  others  => 
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CLOSE  (FILE); 

CLOSE  (NODE) ; 

raise; 
end  OPEN; 

procedure  close  (file  :  in  out  file_type) 

is 

begin 

null;  ~  should  b«  dsfinsd  by  lsplsssntor 
end  close: 

procedure  delete  (FILE  :  in  out  FILE  TYPE) 

is 

begin 

null;  —  should  bs  dsfinsd  by  lsplsssntor 
end  DELETE; 

procedure  RESET  (FILE  ;  in  out  FILE_TY?E; 

MODE  :  FILE_M0DE)  is 

begin 

null;  —  should  bs  dsfinsd  by  lsplsssntor 
end  RESET; 

procedure  reset  (file  ;  in  out  file  type)  is 
begin 

null;  —  should  bs  dsfinsd  by  lsplsssntor 
end  reset: 

function  mode  (file  •  file  TYPE)  return  filemode 

is 

RESULT  ;  FILEJTODE; 
begin 

—  should  bs  dsfinsd  by  lsplsssntor 
return  result; 

end  mode; 

function  name  (file  :  file  type)  return  string  is  separate; 

function  form  (file  :  file  type)  return  string 

is 

RESULT  :  STRING(  1  . .  10) ; 

begin 

—  should  bs  dsfinsd  by  lsplsssntor 
return  result; 

end  form: 

function  is_open  (file  .  file  type)  return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  should  bs  dsfinsd  by  lsplsssntor 
return  result; 

end  is  open; 

—  Input  nnd  output  opsrntlons 
procedure  read  (file  :  file_type; 

ITEM  :  out  ELEMENT  TYPE; 

FROM  :  P0SITIVE_C0UNT)  is 

begin 

null:  —  should  bs  dsfinsd  by  lsplsssntor 
end  READ; 

procedure  read  (file  :  file_type; 
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ITEM  :  OUt  ELEMENT  TYPE)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  read; 

procedure  write(file  :  file  type; 

ITEM  :  ELEMENT  TYPE, 

TO  :  POSITIVE_COUNT)  is 

begin 

null:  —  should  be  defined  by  lapleaentor 
end  WRITE; 

procedure  write  (FILE  :  file_type; 

ITEM  ;  ELEMENTJTYPE)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  write; 

procedure  set_index(File  :  file_type; 

to  :  positive_count)  is  separate; 

function  index  (file  :  file  type)  return  positive_ccunt  is  separate; 

function  size  (file  :  file  type)  return  count 

is  separate: 

function  end_of_file(file  ;  file  type)  return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  should  bo  defined  by  lapleaentor 
return  result; 
end  end  of  file; 
end  direct  io;- 

separate  (cais) 
package  body  sequential_io  is 
USe  NODEDEFINITIONS; ” 

Use  NODE~MANAGEMENT; 
use  DEFINITIONS: 


—  File  aansgeaent 


procedure  create  (FILE 

:  in  out  FILE  TYPE; 

BASE 

:  NODE  TYPE; 

KEY 

:  REL#.TIONSHIP_KEY  :  = 
LATEST_KEY; 

RELATION 

:  RELATION  NAME  := 

DEFAULT  RELATION; 

MODE 

:  FILE  MODE 
INOUT  FILE 

= 

FORM 

:  LIST  TYPE 
EMPTY  LIST 

* 

ATTRIBUTES 

:  LIST  TYPE 
EMPTY  LIST 

= 

ACCESS  CONTROL 

:  LIST  TYPE 

=  EMPTY_LIST; 

is 

begin 

LEVEL  " 

:  LIST~TYPE 

=  EMPTY~LIST) 

null; 

—  should  be  defined  by  lapleaentor 

end  CREATE; 
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procedure  create  (file 

NAME 

MODE 

FORM 

ATTRIBUTES 

ACCESS_CONTROL 
LEVEL  ~ 

BASE  :  NODE  TYPE; 


:  in  out  FILE  TYPE; 


NAMESTRING; 
FIL£_MODE  := 
INOUT_FILE; 
LIST_TYPE  := 
EMPTY_LIST; 
LIST_TYPE  := 
EMPTY_LIST; 
LIST_TYPE  := 
LIST_TYPE  := 


EMPTY  LIST; 

empty“list)  is 


begin 

OPEN  (BASE,  BASEPATH  (NAME). 

(1  =>  APPENDRELATIONSHIPS)) ; 
CREATE  (FILE,  BASE?  LAST  KEY  (NAME), 


LAST_RELATION  (NAME),  MODE,  FORM.  ATTRIBUTES, 
ACCESS_CONTRQL ,  LEVEL) ; 

CLOSE  (BASE)"; 


exception 
when  others  => 


CLOSE  (FILE); 
CLOSE  (BASE) ; 

raise; 

end  CREATE; 


procedure  open  (file  :  in  out  file  type; 

NODE  :  NODE  TYPE; 

MODE  :  FILE  MODE)  is 

begin 

null;  —  should  bs  dsflnsd  by  lsplessntor 

end  open; 

procedure  open  (FILE  ;  in  out  FILEJTYPE; 

NAME  :  NAMESTRING; 

MODE  :  FILEMODE) 

is 

NODE  :  NODE  TYPE 

begin 

case  mode  is 

when  IN  FILE  =>  OPEN  (NODE,  NAME.  (1  =>  READ  CONTENTS) ) ; 
when  OUT  FILE  =>  OPEN  (NODE,  NAME,  U  =>  WRITE_CONTENTS) )  ; 
when  INOUT  FILE  =>  OPEN  (NODE.  NAME. 

(READCONTENTS ,  WRITE_CONTENTS) ) ; 
when  APPENDFILE  =>  OPEN  (NODE,  NAME,  (1=>  APPEND  CONTENTS) )  ; 
end  case; 

OPEN  (FILE.  NODE,  MODE); 

CLOSE  (NODE) ; 
exception 

when  others  => 

CLOSE  (FILE) ; 

CLOSE  (NODE) ; 
raise; 

•nd  OPEN; 

procedure  close(file  :  in  out  file  type) 

is 

begin 

null;  —  should  b«  dsflnsd  by  lsplsssntor 
end  close; 


procedure  delete  (file  :  in  out  file  type) 
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is 

begin 

null; —  should  be  defined  by  lapleaentor 
end  DELETE; 

procedure  reset  (FILE  :  in  out  file_type; 

MODE  :  FILE_MODE)  is 

begin 

null;  —  should  bs  daflnsd  by  laplsasntor 
end  reset; 

procedure  reset  (file  :  in  out  file_type)  is 
begin 

null;  —  should  bs  daflnsd  by  laplsasntor 
end  replace; 

function  mode  (file  :  fil£_type)  return  file_mode 

is 

RESULT  :  FILEMODE; 
begin 

—  should  bs  daflnsd  by  laplsasntor 
return  result: 

end  mode: 

function  name  (file  :  filetype)  return  string 

is 

RESULT  :  STRING (1. .10); 

begin 

—  should  bs  daflnsd  by  laplsasntor 
return  RESULT; 

end  name: 

function  form  (file  :  FiLEjnrPE)  return  string 

is 

RESULT  :  STRING (1. .10) ; 
begin 

—  Should  bs  daflnsd  by  laplsasntor 
return  result; 
end  FORM; 

function  is_open(file  .  file_type)  return  boolean 

is 

RESULT  :  BOOLEAN; 

begin 

—  should  bs  daflnsd  by  laplsasntor 
return  RESULT; 

end  is_0PEN; 

—  Input  and  output  operations 

procedure  read  (FILE  :  FILE_TYPE; 

item  :  out  element_type)  is  separate; 

procedure  write  (FILE  :  FILE_TYPE;  item  :  ELEMENT  TYPE)  is  separa 


function  end  of  file  (file  :  file  type)  return  boolean 

is 

RESULT  ;  BOOLEAN; 
begin 

—  should  bs  daflnsd  by  laplsaantor 
return  RESULT; 
end  END_0F_FILE; 

end  sequential'io; 
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separate  (cais) 
package  body  text  io  is 
USe  NOD£_DEFINITIONS; 
use  NODE_MANAGEMENT; 
USe  IO_DEFINITIONS; 
use  LliT_UTILITIES; 

—  File  Management, 


procedure  create  (file  :  in  out  FILE  TYPE; 

N0DE_TYPE ; 

RELATIONSHIP  KEY  := 

LATEST_KEY ; 

RELATION_NAME  :  = 

DEFAULT_RELATION; 

FILE  MODE  := 

INOUT_FILE; 

LIST  TYPE  := 

EMPTY_LIST; 

LIST_TYPE  :  = 

EMPTY_LIST; 

LIST_TYPE  :=  EMPTY  LIST; 
list~type  ;=  empty J-IST)  is  separate. 

procedure  create  (file  :  in  out  file_type; 

NAME  :  NAMESTRING: 

MODE  ;  FILE_MODE  .= 

INOUT  FILE; 

FORM  :  LISTTYPE  := 

EMPTY  LIST; 

ATTRIBUTES  :  LIST  TYPE  := 

EMPTY  LIST; 

ACCESSCONTROL  :  LIST_TYPE  :=  EMPTYLIST; 

LEVEL  :  LIST~TYPE  :=  EMPTY  LIST)  is 

BASE  :  NODE  TYPE; 
begin 

OPEN  (BASE.  BASEPATH  (NAME) , 

(1  =>  APPENDRELATIONSHIPS) ) ; 

CREATE  (FILE.  BASE.  LASTJCEY  (NAME). 

LASTRELATION  (NAME)-.  MODE.  FORM.  ATTRIBUTES, 

ACCESS  CONTROL,  LEVEL); 

CLOSE  (BASe7 ; 
exception 
when  others  => 

CLOSE  (FILE) ; 

CLOSE  (BASE) ; 
raise, 

end  CREATE; 


procedure  open(file  .  in  out  file  type; 

NODE  :  NODE_TYPE ; 

MODE  :  file_mode)  is  separate; 

procedure  open(file  :  in  out  file  type; 

NAME  :  NAME  STRING; 

MODE  :  FH.E~ MODE)  is 
NODE  :  NODE_TYPE; 
begin 

case  mode  is 

when  IN  FILE  =>  OPEN  (NODE,  NAME, 
(1  =>  READ_CONTENTS) ) ; 

when  out  file  =>  open  (node.  name. 


KEY 

RELATION 

MODE 

FORM 

ATTRIBUTES 

ACCESS_CONTROL 

LEVEL 
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(t  =>  WRITE_CONTENTS)  )  ; 

when  INOUT  FILE  => 

OPEN  (NODE.”  MANE. 

(R£AD_CQNTENTS .  <fRITE_CONTENTS) ) ; 


when  APPEND  FILE  => 

(1 


end  case; 


OPEN  (NODE.  NAME. 

=>  APPEND  CONTENTS)); 


OPEN  (FILE,  NODE.  MODE); 

CLOSE  (NODE) ; 
exception 
when  others  => 

CLOSE  (FILE) ; 

CLOSE  (NODE); 
raise 
end  open; 

procedure  CLOSE  (file  :  in  out  file  type) 

is 

begin 

null;  —  should  bs  dsfinsd  by  lsplsasntor 
end  close; 

procedure  delete  (file  :  in  out  FILE  type)  is  separate; 
procedure  reset  (file  :  in  out  FILE  type; 

NODE  :  FILE  MODE)  is 

begin 

null;  —  should  bs  dsfinsd  by  lsplsasntor 
end  RESET; 

procedure  reset  (file  :  In  out  FILE_TYPE)  is 
begin 

null;  —  should  bs  dsfinsd  by  lsplsasntor 
end  RESET; 

function  mode  (file  :  file  type)  return  filemode  is  separate; 
function  name  (file  :  file_type)  return  string  is  separate; 
function  form(file  :  file_type)  return  string  is  separate; 

function  is_open(file  ;  file_type)  return  boolean 

is 

RESULT  :  BOOLEAN; 
begin 

—  should  bs  dsfinsd  by  laplasntor 
return  RESULT; 
end  is  open; 

—  Control  of  default  Input  and  output  filss 
procedure  set_input(FILE  :  file  type)  is  separate; 
procedure  set_output(file  :  file  type)  is  separate; 
procedure  set_error (file  :  file_type)  is  separate; 
function  standard  input  return  file  type  is  separate; 
function  standard  output  return  file  type  is  separate; 
function  standard  error  return  file  type  is  separate; 
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function 

function 

function 


curr£NT_ input  return  file_type  is  separate; 
current  output  return  file  type  is  separate; 
current_error  return  file_type  is  separate; 


—  Specification  of  line  and  page  lengths 

procedure  set_line_length(file  :  file_type; 

TO  :  COUNT)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  setlinelencth; 

procedure  set_line_length  (to  :  count)  is 
begin 

null;  —  should  be  defined  by  lapleaentor 
end  setlinelength; 

procedure  setpagelength(file  :  FILE  TYPE; 

TO  :  COUNT)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  SETPAGELENGTH; 

procedure  setpagelength  (to  ;  count)  is 
begin 

null;  —  should  be  defined  by  lapleaentor 
end  SET  PAGE  LENGTH; 

function  line  length  (file  :  file_type)  return  count  is 

RESULT  :  COUNT; 

begin 

—  should  be  defined  by  lapleaentor 

return  line  length; 

end  LINE  LENGTH; 

function  line  length  return  count  is 
RESULT  :  COUNT; 

begin 

—  should  be  defined  by  lapleaentor 

return  result; 

end  LINE  LENGTH; 

function  page  length  (file  :  file  type)  return  count  is 
RESULT  :  COUNT; 
begin 

—  should  be  defined  by  lapleaentor 

return  result; 

end  PAGE  LENGTH; 

function  page  length  return  count  is 
RESULT  :  COUNT; 
begin 

—  should  be  defined  by  lapleaentor 

return  result; 

end  PAGE  LENGTH; 


Coluan,  Line  and  Page  Conr rol 
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procedure  new_line(file  :  file  type; 

SPACING  :  POSITIVE  COUNT"  :=  1)  is 

begin 

null;  —  should  b«  defined  by  lsplsnsntor 
end  NEWLINE; 

procedure  new  line  (spacing  :  positive  count  :=  i)  is 
begin 

null;  —  should  bs  dsfinad  by  lspisssntor 
end  new  line, 

procedure  skip_line (file  ;  file  type; 

SPACING  ;  POSITIVE  COUNT*  :=  1)  is 

begin 

null;  —  should  bs  dsfinsd  by  lspisssstor 
end  skip  line  ; 

procedure  skip  line  (spacing  :  positive  count  ;=  d  is 
begin 

null;  —  should  bs  dsfinsd  by  lspisssntor 
end  skip  line; 

Function  endofline  (file  :  file  type)  return  boolean  is 

RESULT  :  BOOLEAN; 
begin 

—  should  hs  dsfinsd  by  lspisssntor 

return  result; 

end  END  OF  LINE; 

Function  end_of_line  return  boolean  is 

RESULT  :  BOOLEAN ; 
begin 

—  should  bs  dsfinsd  by  lspisssntor 

return  result; 

end  END  OF  LINE; 

procedure  new_page(file  :  file  type)  is 
begin 

null;  —  should  bs  dsfinsd  by  lspisssntor 
end  NEWPAGE; 

procedure  newpage  is 
begin 

null;  —  should  bs  dsfinsd  by  lspisssntor 
end  NEW  PAGE; 

procedure  skip_page(file  :  file  type)  is 
begin 

null;  —  should  bs  dsfinsd  by  lspisssntor 
end  skippage; 

procedure  skip  page  is 
begin 

null;  —  should  bs  dsfinsd  by  lspisssntor 

end  skip  page; 

Function  end  of  page  (file  :  file  type)  return  boolean  is 

RESULT  :  BOOLEAN; 
begin 

—  should  bs  dsfinsd  by  lspisssntor 

return  result; 

end  END  OF  PAGE; 

Function  end_of_page  return  boolean  is 
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RESULT  :  BOOLEAN; 
begin 

—  should  bs  defined  by  lapleaentor 
return  result; 

end  end  of  paoe; 

function  end  of  file  (file  :  file_type)  return  boolean  is 

RESULT  :  BOOLEAN; 
begin 

—  should  be  defined  by  lapleaentor 
return  RESULT; 

end  END_OF_FIL£ ; 

function  end  of  file  return  boolean  is 
RESULT  :  BOOLEAN; 
begin 

—  should  be  defined  by  lapleaentor 

return  end_of_file; 
end  END  of  FILE; 


procedure  SET_COL(FILE  :  FILE  TYPE; 

TO~  :  POSITIVE_COUNT)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  set  col; 

procedure  set_col(to  :  positivecount)  is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  SET  COL; 

procedure  set_line(file  :  FILE  TYPE; 

TO  ;  POSITIVECOUNT)  Is 

begin 

null:  —  should  be  defined  by  lapleaentor 
end  set  line; 

procedure  set_line(to  :  positive_count)  is 
begin 

null;  —  should  be  defined  by  lapleaentor 
end  SET  LINE; 


function  col  (file  ;  file_type)  return  positive  count  is 

RESULT  :  POSITIVECOUNT; 

begin 

—  should  be  defined  by  lapleaentor 
return  result; 

end  COL; 

function  col  return  positive  count  is 

RESULT  :  POSITIVE_COUNT; 

begin 

—  should  be  defined  by  laplesentor 
return  result: 

end  COL; 

function  line  (file  ;  file  type)  return  positive  count  is 

RESULT  :  POSITIVE_COUNT; 

begin 

—  should  be  defined  by  lapleaentor 
return  result; 

end  line; 
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function  lime  return  positive  count  is 

RESULT  :  POSITIVE_COUMT; 

begin 

—  should  ba  defined  by  laplesentor 
return  RESULT; 

end  LINE; 

function  pace  (file  ;  file  type)  return  pqsitive_coukt  is 

RESULT  :  POSITIVE_COUMtT 

begin 

—  should  be  defined  by  laplesentor 
return  Rr  XT; 

end  PACE; 

function  pace  return  positive  count  is 

RESULT  :  POSITI VE_COUNT ; 
begin 

—  should  be  defined  by  laplesentor 
return  RESULT; 

PAGE; 
end  PAGE; 


--  Character  Input-Output 

procedure  get  (file  :  filetype;  item  :  out  character)  is 
begin 

null:  —  should  be  defined  by  laplesentor 
end  get; 

procedure  get  (item  :  out  CHARACTER)  is 
begin 

null;  ~  should  be  defined  by  laplesentor 
end  GET; 

procedure  PUT  (FILE  :  FILE_TYPE;  ITEM  :  CHARACTER)  is 
begin 

null;  —  should  be  defined  by  laplesentor 
end  PUT; 

procedure  put  (item  :  character)  is 
begin 

null;  —  should  be  defined  by  laplesentor 
end  put; 


—  String  Input-Output 

procedure  GET  (FILE  :  FILE_TYPE;  item  :  out  STRING)  is 
begin 

null;  —  should  be  defined  by  laplesentor 
end  GET; 

procedure  get  (item  :  out  string)  is 
begin 

null;  —  should  be  defined  by  laplesentor 
end  GET; 

procedure  pur  (file  :  filetype;  item  :  string)  is 
begin 

null;  —  should  be  defined  by  laplesentor 
end  PUT; 


Page  3-354 


280 


PROPOSED  MII.-STD-f  \|S 
31  JAM  ARY  I9K.S 


procedure  put  (item  :  string)  is 
begin 

null;  —  should  ba  defined  by  lapleaentor 
end  PUT; 

procedure  get_line(file  :  file_type; 

ITEM-  :  out  STRING; 

LAST  :  OUt  NATURAL)  is 

begin 

null;  —  should  bs  defined  by  lapleaentor 
end  GET_LINE; 

procedure  GET_LINE (ITEM  :  out  STRING: 

LAST- :  out  NATURAL)  is 

begin 

null;  —  should  bs  defined  by  lapleaentor 
end  GET  LINE; 

procedure  putline (file  :  file_type;  item  :  string)  is 
begin 

null;  —  should  be  defined  by  lapleaentor 
end  PUT  LINE; 

procedure  putlineutem  :  string)  is 
begin 

null;  —  should  be  defined  by  lapleaentor 
end  put  line; 

—  generic  package  for  Input-Output  of  Integer  Types 
package  body  integer  io  is  separate; 

—  generic  package  for  Input-Output  of  Floating  Point  Types 
package  body  float  io  is  separate; 

—  generic  package  for  Input-Output  of  Fixed  Point  Types 
package  body  fixedio  is  separate; 

—  generic  package  for  Input-Output  of  Enuaeratlon  Types 
package  body  enumeration  io  is  separate; 

end  TEXT  10; 


separate  (CAIS) 

package  body  scrolljterminal  is 
use  N0DE_DEFINITI0NS; 
use  NODE-MANAGEMENT; 
use  DEFINITIONS; 
use  TEXT_I0; 

procedure  set  position  (terminal  :  file  type; 

POSITION  :  POSITION_TYPE)_ 

is 

begin 

null;  —  should  be  defined  by  lapleaentor 
end  SET_P0SITI0N; 

procedure  set_position  (position  :  position  type)  is 

begin 

SET  POSITION  (CURRENT_OUTPUT ,  POSITION) ; 
end  SET  POSITION; 
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function  GET_POSITION  (TERMINAL  :  FILE_TYPE) 
return  position  type 

ia 

RESULT  :  POSITION_TYPE; 
begin 

--  should  be  defined  by  lapleaentor 
return  result; 
end  GET_P0SITI0N; 

function  get_position  return  position_type  ia 
begin 

return  get_position  (curremt_output)  ; 
end  GET  POSITION; 


function  terminal_size  (terminal  ;  file_type) 

return  position_type 

ia 

RESULT  :  POSITIONTYPE; 
begin 

—  should  be  defined  by  lapleaentor 
return  result; 
end  TERMINAL  SIZE; 

function  terminal  size  return  position  TYPE  is 
begin 

return  terminal  size  (current jjutput)  ; 
end  terminal  size; 


procedure  SETTAB 

(TERMINAL  :  FILE  TYPE; 

KIND  :  TABJENUMERATION  :  =  HORIZONTAL) 

ia 

begin 

—  should  be  defined  by  lapleaentor 
null; 

end  SET  TAB; 

procedure  set_tab(kind  :  tabenumeration  ;=  horizontal)  ia 
begin 

SETTAB  (CURRENTINPVT.  KIND) ; 
end  SET  TAB; 


procedure  cleartab 

(TERMINAL  :  FILEJTTPE; 

KIND  :  TAB_InUMERATI0N  ;=  HORIZONTAL) 

ia 

begin 

—  should  be  defined  by  lapleaentor 
null; 

end  CLEAR  TAB; 

procedure  clear_tab(kind  :  tab  enumeration  :=  horizontal)  ia 
begin 

CLEAR_TAB  (CURRENT_OUTPUT .  KIND); 
end  CLEAR  TAB; 


procedure  tab  (terminal  :  file  type; 

KIND  :  TABENUMERATION  :=  HORIZONTAL; 

COUNT  :  POSITIVE  ;=  1) 

is 
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begin 

—  should  b«  defined  by  Implementor 
null; 
end  TAB; 

procedure  tab(kind  :  tab_enumeration  :=  horizontal; 

COUNT  :  POSITIVE  :=  1)  is 

begin 

TAB  (CURRENT_OUTPUT.  KIND,  CCNT)  ; 
end  TAB; 


procedure  bell  (terminal  :  file_type) 

is 

begin 

—  should  be  defined  by  lsplesentor 
null; 

end  BELL; 

procedure  bell  is 
begin 

BELL  (CURRENTOUTPUT) ; 

end  bell; 

procedure  put  (terminal  :  fili  TYPE;  ITEM  ;  character) 

is 

begin 

—  should  be  defined  by  lsplesentor 
null; 

end  PUT; 

procedure  put  (item  .  CHARACTER)  is 
begin 

PUT  (CURRENTOUTPUT,  ITEM); 
end  PUT; 


procedure  put  (terminal  :  file  TYPE;  ITEM  :  STRING)  is 
begin 

for  INDEX  in  ITEM ‘FIRST  ..  ITEM ‘LAST  loop 
PUT  (TERMINAL,  ITEM  (INDEX)); 
end  loop; 
end  PUT; 


procedure  PUT  (item  :  string)  is 
begin 

PUT  (CURRENT_OUTPUT,  ITEM); 
end  put; 


procedure  set_echo (terminal  :  file_type; 

TO  :  BOOLEAN  :=  TRUE) 

is 

begin 

—  should  be  defined  by  lsplesentor 
null; 

end  set  echo; 


procedure  set_echo(to  :  boolean  :=  true)  is 
l>egin 

SET_ECHO  (CURRENTINPUT,  TO); 

end  ""set  echo  ; 
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function  echo  (terminal  :  fil£_type)  return  boolean 

is  separate; 

function  echo  return  boolean  is 
begin 

return  echo  (current_input)  ; 
end  ECHO; 


function  maximum_function_key  (terminal  :  file  type) 
return  natural 

is 

RESULT  :  NATURAL; 
begin 

—  should  bs  defined  by  Implementor 
return  RESULT; 
end  MAXIMUM_FUNCTION_KEY ; 

function  maximum_function_key  return  natural  is 
begin 

return  maximum  function  key  (currentinput)  ; 

end  MAXIMUM  FUNCTION  KEY? 


procedure  get  (terminal  :  file_type; 

ITEM  ;  out  CHARACTER; 

KEYS  :  out  FUNCTION_KEY_DESCRIPTOR>  is 

begin 

null;  —  should  bs  defined  by  lsplesentor 
end  GET; 

procedure  get  (item  :  out  CHARACTER; 

KEYS  ;  out  FUNCTION  KEY  DESCRIPTOR)  is 

begin 

GET  (CURRENTOUTPUT,  ITEM,  KEYS); 
end  GET; 


procedure  GET  (TERMINAL  :  FILE_TYPE ; 

ITEM  :  OUt  STRING” 

LAST  :  OUt  NATURAL; 

KEYS  :  OUt  FUNCTION  KEY  DESCRIPTOR) 


begin 

null;  —  should  be  defined  by  implementor 
end  GET; 


is 


procedure  GET  (item  :  out  STRING; 
LAST  :  OUt  NATURAL; 


KEYS  :  OUt  FUNCTION_KEY_DESCRIPTOR) 

begin 

GET  (CURRENT_INPUT,  ITEM,  LAST.  KEYS); 
end  GET; 


is 


function  FUNCTION  KEY  COUNT 

(KEYS  :  FUNCTION_KEY_DESCR I PTOR) 

return  natural 

is 

RESULT  :  NATURAL; 
begin 

—  should  be  defined  by  Implementor 
return  result; 
end  FUNCTION  KEY  COUNT; 
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procedure  function_key 

(KEYS  :  FUNCTION  KEY  DESCRIPTOR; 

INDEX  :  POSITIVE? 

KEY_IDENTIFIER  :  out  POSITIVE; 

POSITION  :  out  NATURAL) 

is 

begin 

—  should  b«  defined  by  laplaasntor 
null; 

end  FUNCTION_KEY ; 
procedure  functionj.ey_name 

(TERMINAL  "FILE  TYPE; 

KEY_IDENTIFIER  :  POSITIVE; 

KEY  NAME  :  out  STRING; 

LAST  :  out  POSITIVE) 

ia 

begin 

—  should  be  defined  by  lapleaentor 
null; 

end  FUNCTION  KEY  NAME; 
procedure  function  key  name 

(KEY_IDENTIFIER  :  POSITIVE; 

KEY  NAME  :  out  STRING; 

LAST  :  out  POSITIVE)  is 

begin 

FUNCTION  KEY  NAME 

(CURRENT  INPUT.  KEY  IDENTIFIER.  KEY  NAME.  LAST) ; 
end  FUNCTION  KEY  NAME;  ~ 


procedure  new  line  (terminal  :  file_type; 

count  :  positive  :=  t)“is  separate; 

procedure  new  line  (count  :  positive  :=  l)  is 

begin 

new  line  (CURRENTOUTPUT,  COUNT); 
end  NEW  LINE; 


procedure  newpage (terminal  ;  file_type)  ia  separate; 

procedure  new  page  ia 
begin 

NEWPAGE  (CURRENT  OUTPUT) ; 

end  new  page; 

end  SCROLL  TERMINAL; 

separate  (cais) 
package  body  pageterminal  ia 
U8e  NODE_DEFINITIONS; 
use  node ^management ; 
use  IO_DEFINITIO.'S; 
use  TEXT_IO; 

procedure  SET_POSITION (TERMINAL  :  FILE  TYPE; 

.  POSITION  :  POSITION  TYPE) 

IS 

begin 

null;  —  should  bs  dsflnsd  by  lapisasntor 
end  SET  POSITION; 
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procedure  set_position  (position  :  position_type)  ia 
begin 

SET  POSITIOR  (CURRENT  OUTPUT,  POSITIOR); 
end  SET  POSITION; 


function  GET_POSITION  (TERMINAL  :  FILE  TYPE) 

'return  position_type 

ia 

RESULT  :  POSITION_TYPE; 
begin 

—  should  be  defined  by  lapleaentor 

return  result; 
end  GET_POSITIOR; 

function  get  positior  return  position_type  ia 
begin 

return  composition  (curreht_output)  ; 

end  GET  POSITION; 


function  terminal_size  (terminal  :  file  type) 

return  position  type 

ia 

RESULT  :  POSITION_TYPE; 

begin 

—  should  be  defined  by  lapleaentor 
return  result; 
end  TERMINALSIZE; 

function  terminalsize  return  POSITION_TYPE  ia 
begin 

return  terminalsize  (currentoutput)  ; 
end  terminal  size; 


procedure  settab 

(TERMINAL  :  FILETYPE; 

KIND  :  TABENUMERATION  :=  HORIZONTAL) 

ia 

begin 

—  should  be  defined  by  lapleaentor 
null; 

end  set  tab; 


procedure  set _tab (kind  :  tab  enumeration  :=  horizontal)  ia 
begin 

SETTAB  (CURRENTINPUT ,  KIND); 
end  SET  TAB; 


procedure  clear _Tab 

(TERMINAL  :  FILE  TYPE; 

KIND  :  TAB  ENUMERATION  :  =  HORIZONTAL) 

ia 

begin 

—  should  be  defined  by  lapleaentor 
null; 

end  CLEAR  TAB; 

procedure  clear_tab(kind  .  tab  enumeration  .=  horizontal)  ia 

begin 

CLEAR_TAB  (CURRENT_OUTPUT,  KIND); 
end  CLEAR  TAB; 
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procedure  tab  (terminal  :  file_type; 

KIND  :  TAB_ENUMERATI ON  :=  HORIZONTAL; 

COUNT  :  POSITIVE  :=  1) 

is 

begin 

—  should  be  defined  by  laplesantor 
null; 
end  tab; 

procedure  tab(kind  :  tabenumeration  :=  horizontal; 

COUNT  :  POSITIVE  :=  1)  is 

begin 

TAB  (CURRENT_OUTPUT.  KIND.  COUNT) ; 
end  TAB; 


procedure  bell  (terminal  :  file_type) 

is 

begin 

—  should  be  defined  by  lopleoentor 
null; 

end  BELL: 

procedure  bell  is 
beg!" 

BELL  (CURRENTOUTPUT)  ; 
end  BELL; 


procedure  put  (terminal  :  file_type; 

ITEM  :  CHARACTER) 

is 

begin 

—  should  be  defined  by  laplesentor 
null; 
end  put; 

procedure  put  (item  :  character)  is 
begin 

PVT  (CURRENTOUTPUT.  ITEM) ; 
end  put; 


procedure  put(terminal  :  file  type;  item  :  string)  is 
begin 

for  index  in  item’FIRST  ..  item -last  loop 
PUT  (TERMINAL.  ITEM  (INDEX)); 

end  loop; 
end  put; 


procedure  puT(item  :  string)  is 

begin 

PUT  (CURRENT  OUTPUT,  ITEM) ; 
end  PUT; 


procedure  set_echo (terminal  :  file_type; 

TO  :  BOOLEAN  :  TRUE) 

is 

begin 

—  should  be  defined  by  loplenentor 
null; 

end  SET  ECHO; 
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procedure  set_echo  (to  .  boolean  :=  true)  ia 
begin 

SET  ECHO  (CURRENT_INPUT,  TO); 
end ’SET  ECHO; 


function  echo  (terminal  .  file_type>  return  boolean 

ia  separate; 

function  echo  return  boolean  ia 
begin 

return  ECHO  (CURR£NT_INPUT)  ; 
end  echo; 


function  maximumfunctionjcey  (terminal  :  filetype) 
return  natural 

ia 

RESULT  :  NATURAL; 
begin 

—  should  bs  defined  by  lapleaentor 
return  result; 
end  MAXIMUMFUNCTIONJCEY: 

function  maximumfunctionjcey  return  natural  ia 
begin 

return  maximumfunctionkey  (currentinput)  ; 
end  maximum  function  key 7 


procedure  get(tf»xinal  ;  FILE_TYPE; 

ITEM  :  out  CHARACTER; 

KEYS  ;  out  FUNCTI ON_KEY_DESCRIPTOR)  ia 

begin 

null:  —  should  be  defined  by  lapleaentor 
end  GET; 

procedure  get  (item  :  out  character; 

KEYS  :  out  FUNCTIONKEYDESCRIPTOR)  ia 

begin 

GET  (CURRENTOUTPW,  ITEM,  KEYS); 
end  GET; 


procedure  get  (terminal  :  file_type; 

ITEM  :  OUt  STRING? 

LAST  :  OUt  NATURAL; 

KEYS  ;  OUt  FUNCTION JCEY_DESCRIPTOR)  ia 

begin 

null;  --  should  be  defined  by  lapleaentor 
end  GET; 

procedure  GET  (item  :  out  string; 

LAST  :  out  NATURAL; 

KEYS  :  in  OUt  FUNCTION  KEY  DESCRIPTOR)  is 

begin 

GET  (CURRENT_INPUT.  ITEM,  LAST,  KEYS); 
end  GET; 


function  function  jcey_couxt 

(KEYS  :  FUNCTION_KEY_DESCRIPTOR) 
returnNATURAL 
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begin 

—  should  ba  defined  by  Implementor 
null; 

end  FUNCTION_KEY__COUNT ; 


procedure  functionjcey 

(KEYS 

INDEX 

KEY__IDENTIFIER  : 
POSITION 

is 


FUNCTION  KEY  DESCRIPTOR; 

positive" 

out  POSITIVE; 
out  NATURAL) 


begin 

—  should  be  defined  by  implementor 
null; 

end  function  key; 


procedure  function_key_name 

(TERMINAL  “  :  FILE_TYPE; 

KEYIDENTIFIER  :  POSITIVE; 

KEYNAME  :  out  STRING; 

LAST  :  OUt  POSITIVE) 

is 

begin 

—  should  be  defined  by  implementor 
null; 

end  FUNCTION  KEY  NAME; 


procedure  function  key  name 

(KEYIDENTIFIER  "POSITIVE; 

KEY  NAME  :  out  STRING; 

LAST  :  OUt  POSITIVE)  is 

begin 

FUNCTIONKEY  NAME 

(CURRENTINPUT.  KEYIDENTIFIER.  KEYNAME,  LAST); 
end  FUNCTION  KEY  NAME; 


procedure  deletecharacter (terminal  :  file  type; 

count  :  positive  :=  l)  is  separate; 

procedure  delete_character (count  :  positive  :=  i)  is 

begin 

DELETECHARACTER  (CURHENT_OUTPUT .  COUNT); 
end  DELETE  CHARACTER; 


procedure  delete_line (terminal  :  file_type; 

count  :  positive)  is  separate; 

procedure  delete_line (count  :  positive  :=  1)  is 

begin 

DELETE_LINE  (CURRENT_OUTPUT,  COUNT) ; 
end  DELETE  LINE; 


procedure  erase_character(terminal  ;  file_type; 

COUNT  :  POSITIVE  :=  i)  is  separate; 

procedure  erase_character (count  :  positive  :=  1)  is 

begin 

ERASE ^CHARACTER  (CURRENT_OUTPUT.  COUNT) ; 
end  ERASE  CHARACTER; 
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procedure  erase_in_di splay 
(TERMINAL  ” :  FIL£_TYPE; 

SELECTION  :  SELECT_ENUMERATION)  is  separate; 

procedure  erase_in_display 

(SELECTION”  :  SEL£CT_ENUMERATION)  is 

begin 

ERASE  IN  DISPLAY  (CURRENT_OUTPUT ,  SELECTION); 
end  ERASE  IN  DISPLAY; 


procedure  erase_in_line (terminal  :  file  type; 

SELECTION  :  SELECT_ENUMERATION)  is  Separate; 

procedure  erase_in_line  (selection  :  select_enumeration)  is 

begin 

ERASE_IN_LINE  (CURRENT_OUTPUT,  SELECTION)  ; 
end  ERASE  IN  LINE; 


procedure  insert  space (terminal  :  file  type; 

count  :  positive  :=  i)  is  separate; 

procedure  insert_sp ace (count  :  positive  :=  1)  is 

begin 

INSERTSPACE  (CURRENTOUTPUT,  COUNT); 
end  INSERT  SPACE; 


procedure  insert  line  (terminal  :  filetype; 

count  ;  positive  :=  i)  is  separate; 

procedure  insert_LINE(count  :  POSITIVE  :=l)  is 

begin 

INSERT  LINE  (CURRENT  OUTPUT,  COUNT); 
end  INSERT  LINE; 


function  graphicrenditionsupport 
(TERMINAL  :  FILE  TYPE; 

RENDITION  :  GRAPHICRENDITIONARRAY) 

return  boolean  is  separate; 

function  graphic  rendition  support 

(RENDITION  :  GRAPHICRENDITIONARRAY) 

return  boolean  is 

begin 

return  graphic_rendition_support 

(CURRENT_OUTPUT ,  RENDITION); 
end  GRAPHIC  R  NDITION  SU1  "IRT; 


procedure  select_graphic_rendition 
(TERMINAL  ;  FILE_TYPE ; 

RENDITION  :  GRAPHICRENDITIONARRAY  .= 

default_craphic_rendition)  is  separate; 

procedure  self.ct_graphic_rendition 

(RENDITION  GRAPHICRENDITIONARRAY  := 
DEFAULT_GRAPHIC_RENDITION)  is 

begin 

SELECTGRAPHIC  RENDITION  (  CURRE  NT  _  OUTPUT  ,  RENDITION), 

end  select  graphic  rendition; 
end  PAGE  TERMINAL; 
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separate  (cais) 

package  body  form  terminal  is 
use  N0DEJ5EFINITI0NS; 
use  NODE_MANAGEMENT; 

Use  IO_DEFINITIONS; 
use  TEXT_IO; 

function  MAXIMUM_FUNCTION_KEY  (TERMINAL  :  file_type) 
return  natural  is  separate; 

function  maximum_function_key  return  natural  is 
begin 

return  maximum_functiqn_key  (current_ input) ; 
end  MAXIMUM  FUNCTION  KEY? 


procedure  define  qualified  area 

(FORM  :  in  OUt  FORM  TYPE; 

INTENSITY  :  AREA_INTENSITY  ;=  NORMAL; 

PROTECTION  :  AR£A_PROTECTI ON  :=  PROTECTED; 

INPUT  :  AREAINPUT  := 

GRAPH I C~CHARACTERS ; 

VALUE  :  AREAVALUE  :=  NO  FILL)  is  Separate; 

procedure  remuvearea  qualifier  (form  :  in  out  form  type)  is 
separate ; 

procedure  set_position(form  :  in  out  form  type; 

position  :  P0SITI0N_TYPE)  is  separate; 

procedure  next jjualified  area (FORM  :  in  out  form  type; 

count  :  POSITIVE  :=  l)  is  separate; 

procedure  put  (form  :  in  out  FORMTYPE; 

ITEM  :  PRINT ABLE  CHARACTER) 

is 

begin 

null;  —  should  be  dsflned  6y  lsplsssntor 
end  put; 

procedure  put(form  :  in  out  form  type;  item  :  string)  is 
begin 

for  INDEX  in  ITEM'FlRST  ITEM  'LAST  loop 

PUT  (form.  ITEM  (INDEX));  —  writs  a  slngls  character 
end  loop; 
end  put: 


procedure  erase_area (form  :  in  out  form_type)  is  separate; 

procedure  erase  form (form  :  in  out  form  type)  is  separate; 

procedure  activate  (terminal  :  file  type; 

form  :  in  out  form_TYPE)  is  separate, 

procedure  get(form  in  out  FORM  TYPE; 

ITEM  :  out  PRINTABLE  CHARACTER) 

is 

begin 

--  should  be  defined  by  lsplesentor 
null ; 
dnd  get. 
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procedure  get  (form  :  in  out  form  type; 

ITEM  :  out  STRING)  is 

begin 

for  INDEX  in  ITEM-FIRST  ..  ITEM  'LAST  loop 

GET  (FORM,  ITEM  (INDEX));  —  Read  a  single  character 
end  loop; 
end  GET; 


function  is_form_updated  (form  :  form_type)  return  boolean 

is  separate; 

function  terminationjcey  (form  .  form  type)  return  natural 

is  separate; 

function  form_size  (form  :  form  type)  return  position  type 

is  seperate; 

function  terminal  size  (terminal  ;  file  type) 

return  POSITION  TYPE  is  seperate; 

function  terminal  size  return  position  type  is 
begin 

return  terminal_size  (CURREirr_0UTPUT) ; 
end  TERMINAL  SIZE; 


function  AREAQUALIFIERREQUIRESSPACE  (FORM  ;  FORM  TYPE) 

return  boolean  is 

RESULT  :  BOOLEAN; 
begin 

—  should  he  defined  by  lsplesentor 

return  result; 

end  areajjualifierrequiresspace; 
function  areaqualifierrequiresspace 

(TERMINAL  :  FILE  TYPE)  return  BOOLEAN  is 
RESULT  :  BOOLEAN; 

begin 

—  ehould  be  defined  by  lsplesentor 
return  result; 

end  AREA_QUALIFIER_REQUIRES_SPACE; 

function  areajjualifier  requires  space  return  boolean  is 
begin 

return  areajjualifier  requires  space  ( current jjutput)  ; 

end  AREA JJUALIF IER  REQUIRES  SPACE ; 

end  FORM  TERMINAL; 

separate  (cais) 
package  body  magnetic  tape  is 
use  NODEDEFINITIONS; 
use  NODE  MANAGEMENT; 

procedure  mount (tape  drive:  in  file  type; 

TAPE  NAME:  in  REELNAME; 

DENSITY  in  POSITIVE)  is  separate; 
procedure  load-unlabeled(tape_drive:  in  file  type; 

DENSITY  in  POSITIVE, 

BLOCK  SUE:  in  POSITIVE) 

is  separate; 

procedure  initialize jw.abeled(tape_drive:  in  file  type) 

is  separate; 
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procedure  load_labeled(tape_drive:  in  file  type; 

VOLUME_IDENTIFIER:  in  VO!.UME_STRING; 
DENSITY;  in  POSITIVE; 

BLOCX_SIZE.  in  POSITIVE) 

is  separate; 

procedure  initialize_labeled(tape_drive.  in  filejiype; 

VOLUME_IDENTIFIER:  in  VOLUME_STRING; 
ACCESSIBILITY:  in  CHARACTER  :=•  •) 

is  separate; 

procedure  unload  (tape  drive,  in  file_type) 


procedure  dismount (tapedrive:  in  file  type) 


is  separate; 
is  separate; 


function  is_loaded(tape_drive:  in  file  type) 
return  boolean  is  separate; 
function  is_mouvted  (tape_drive  ;  in  file_typej 
return  boolean  is  separate; 
function  tape_status(tape_drive:  in  file_type) 
return  tape  position  is  separate; 
procedure  rewind_tape(tape_drive:  in  file  type) 

is  separate; 

procedure  skipjtape_marks(tape_drive:  in  file  type; 

NUMBER:  in  INTEGER  : =1 ; 
TAPESTATE:  out  TAPE  POSITION) 

is  separate; 

procedure  mrite  tape  marx (tape_drive :  file  type; 

NUMBER:  POSITIVE  :=1; 

TAPE  STATE:  Out  TAPE  POSITION) 

is  separate; 

procedure  volume_header(tape_drive:  file_type; 

VOLUMEIDENriFIER:  VOLUME  STRING; 
ACCESSIBILITY:  CHARACTER  7='  •) 

is  separate; 

procedure  FILE_HEADER(TAPE_DRIVE:  FILE  TYPE; 

FILE_IDENTIFIER:  FILE_STRING; 
EXPIRATIONDATE:  STRING  :=*  99360"; 
ACCESSIBILITY:  CHARACTER  :=’  -) 

is  separate; 

procedure  endfilelabel  (tape  drive  :  file  type) 

is  separate; 

procedure  readlabel (tape  drive  :  file  type; 

LABEL:  OUt  LABELSTRINC) 

is  separate; 


end  MAGNET  I  C_T  APE; 

package  file  import  export  is 

use  NODE_DEFINITIONS ; 

procedure  import  (node  .  node_type; 

hostfilename  :  string)  is  separate; 
procedure  import  (name:  in  namestring; 

HOST  FILE  NAME:  in  string)  is  separate; 
procedure  export  (node  :  node  type, 

HOST_FILE_Name  :  STRING)  is  separate; 
procedure  export  (name:  in  namestring; 

host  file  name:  in  string)  is  separate; 

end  FILE  IMPORT  EXPORT; 
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package  body  list  utilities  is 
use  NODE_DEFINITIONS; 
use  nodejianagement  ; 

procedure  copy(to_list:  list  type; 

FROM_LIST:  LISTJYPE) 

is  separate; 

function  to  list  (liststring:  string) 

return  list  type 
is  separate: 

function  to_text  (list_item  ;  listjiype) 

return  list  text 
is  separate; 

function  IS_EQUAL(LIST1 :  LIST  TYPE; 

LISTS:  LIST_TYPE) 
return  boolean  is  separate; 

function  extract  (list  :  list  type; 

POSITION  :  POSITION_COUNT) 
return  list_type 

is  separate; 

function  extract  (list  :  LIST  TYPE; 

NAMED  :  NAMESTRING) 

return  list  type 

is  separate; 

function  extract  (list  :  list  type; 

NAMED  :  TOKEN  TYPE) 

return  listjtype 

is  separate; 

procedure  replace  (list  :  in  out  list  type: 

LISTITEM  :  LIST  TYTs” 

POSITION  :  POSITIONCOUNT) 

is  separate-; 

procedure  replace  (list  :  in  out  list_type; 

LIST_ITEM  ;  LIST  TYPE? 

NAMED  :  NAMESTRING) 
is  separate; 

procedure  replace  (list  :  in  out  list  type; 

LISTITEM  :  LIST  TYPE? 

NAMED  :  TOKEN  TYPE) 

is  separate; 

procedure  insert  (list  :  in  out  list  type; 

LIST  ITEM  :  LIST  TYPE; 

POSITION  :  COUNT) 

is  separate; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  :  LIST_TYPe” 

NAMED  :  NAMESTRING; 

POSITION  :  COUNT) 

is  separate; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  ;  LIST_TYPE~ 

NAMED  :  TOKEN_TYPE ; 

POSITION  :  COUNT) 

is  separate; 

function  position  by  value  (list  :  list  type; 

VALUE  :  LISTJYPE 
START_POSITION:  POSITION_COUNT 
:=  POSITION_COUNT- FIRST? 
ENDPOSITION”  POSITION  COUNT 
:=  POSITION  COUNT 'LAST) 

return  position  count  is  separate; 
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function  set_extract 

(LIST  :  LIST_TYPE ; 

POSITION  :  POSITION_COUNT; 

LENGTH  :  POSITIVE* :=  POSITIVE ‘LAST) 

return  list  text 

ia  separate; 

procedure  splice  (list  :  in  out  list  TYPE; 

POSITION  :  POSITIQN_COUNT ; 

SUB_LIST  :  LIST_TEXT) 

is  separate: 

procedure  splice  (list  :  in  out  list_type; 

POSITION  :  POSITION_COUNT; 

SUB_LIST  ;  LIST_TYPE) 

is  separate; 

procedure  delete  (list  :  in  out  list  type; 

POSITION  :  POSITION_COUNT) 

is  separate; 

procedure  delete  (list  :  in  out  list_type; 

NAMED  :  NAMESTRING) 

is  separate ; 

procedure  DELETE  (LIST:  inout  LIST  TYPE; 

NAMED:  TOKENTYPE) 

is  separate; 

function  GET_LIST_KIND(LIST:  LIST  TYPE) 
return  listkind  ia  separate; 

'unction  get  item  kind  (list  .  listtype) 
return  listkind  is  separate; 
function  get_item_kind(list  .  list  type; 

POSITION  :  PollTION  COUNT) 

return  itemkind 

is  separate; 

function  get  item  kind  (list  :  list  type; 

NAMED  :  NAMESTRING) 

return  item  kind 

is  separate; 

procedure  merge  (front  :  list  type; 

BACK  :  LISTTYPE; 

RESULT  :  in  Out  LIST  TYPE) 

is  separate; 

furn  on  LENGTH  (LIST  .  list  type)  return  COUNT 

is  separate; 

pro<  lure  item_name  (list  :  list  type; 

POSITION  :  POSITION_COUNT; 

NAME  :  out  TOKEN  TYPE; 

NAME  RANGE  :  out  POSITIVE) 
is  separate; 

fun'  ion  ITEM  NAME  (LIST  :  LIST  TYPE; 

POSITION  :  POSITION_COUNT) 
return  name  string 

is  separate; 

function  position_by_name  (list  :  list  type; 

NAMED  :  NAME_STRING) 

return  position  "count 

is  separate; 

func  ion  POSITION  BY  NAME  (LIST  :  LIST  TYPE; 

NAMED  :  TOKEN_TYPE) 

return  position_type 

is  separate; 

funr  l.ion  TEXT_LENGTH  (LIST  :  LIST  TYPE) 

return  natural 
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is  separate; 

function  TEXT_L£NGTH  (LIST  :  LIST  JYPE; 

POSITION  :  POSITIONCOUWT) 

return  positive 

is  separate; 

functior  TEXT_L£NGTH  (LIST  :  LIST  JYPE; 

NAKED  NAMESTRING) 

return  positive 

is  separate; 

function  TEXT  LENGTH  (LIST  :  LIST_TYPE; 

NAMED  :  TOKEN  JYPE) 

return  positive 

is  separate; 

package  IDEWTIFIERJTEN  is 

procedure  TO  token  (identifier;  in  namestring; 

TOKEN:  out  TOKEN  JYPE' 

is  separate; 

function  TO  JEXT  (LIST  JTEM:  in  TOKEN  TYPE) 
return  name  string 

is  separate; 

function  is  equal  (token i  :  in  token  jype,- 

TOKENS:  in  TOKEN  TYPE) ; 
return  boolean  is  separate; 


procedure  extract  (LIST .  in  LIST  TYPE; 

POSITION:  in  POSITIONCOUWT; 
TOKEN:  out  TOKENJTYPE) 

is  separate; 

procedure  extract  (list.-  In  LISTJYPE; 

NAMED:  in  NAME_STRING; 

TOKEN:  out  TOKEN  TYPE) 

is  separate; 

procedure  extract  (LIST:  in  list  TYPE; 

NAMED:  in  TOKENTYPE ; 

TOKEN:  out  TOKEN  TYPE) 

is  separate; 

procedure  replace  (LIST:  in  out  list  type; 

LIST  ITEM:  in  TOKEN JYPE; 
POSITION:  in  POSITION_COUNT) 

is  separate; 

procedure  replace  (LIST:  in  out  list  type; 

LIST  JTEM :  in  TOKEN  JYPE ; 
NAMED:  in  TOKEN  TYpI) 

is  separate; 

procedure  replace  (LIST :  in  out  list  jype  ; 

LIST  JTEM :  in  TOKEN  JYPE; 
NAMED:  in  TOKEN  TYPE) 

is  separate; 

procedure  insert(list.  in  out  list  type; 

LIST  ITEM:  in  TOKEN  TYPE; 
POSITION:  in  COUNT) ~ 

is  separate; 

procedure  insert  (LIST:  in  out  list  type; 

LIST  ITEM:  in  TOKEN  TYPE; 
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NAMED:  in  NAMESTRING: 

POSITION:  in  COUNT) 

is  separate; 

procedure  insert(list:  in  out  list  type: 

LIST_ITEM :  in  TOKEN_TYPE; 

NAMED:  in  TOKEN_TYPE ; 

POSITION:  in  COUNT) 

is  separate; 

function  position_by_value  (list  :  in  list_type; 

VALUE:  in  TOKEN_TYPE; 

START_POSITION:~in 
POS ITION_COUNT  := 

POSITION~COUNT ‘FIRST • 

END_POSITION :  in 

POSITIQN_COUNT  := 

POS ITION_COUNT ‘ LAST) 
return  position  count  is  separate; 

end  IDENTIFIER_ITEM ; 

generic 

type  number  is  range  <>; 
package  integer  item  is 

function  extract  (list  :  list  type; 

POSITION  :  POSITIONCOUNT) 
return  number 

is  separate; 

function  extract  (LIST  :  LIST  TYPE; 

NAMED  :  NAME  STRING) 

return  number 

is  separate; 

function  fxtract  (LIST  :  LIST  TYPE; 

NAMED  :  TOKENTYPE) 

return  number 

is  separate; 

procedure  replace  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

POSITION  :  POSITION_COUKT) 
is  separate' 

procedure  replace  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  NAMESTRING) 
is  separate: 

procedure  replace  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  T  0KEN_TYPE) 
is  separate; 

procedure  insert  (list  :  in  out  list  type: 

LIST_ITEM  :  NUMBER; 

POSITION  :  COUNT) 

is  separate; 

procedure  insert  (list  :  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  NAMESTRING; 

POSITION  :  COUNT) 

is  separate; 

l  rocedure  insert  (list  .  in  out  list  type; 

LIST_ITEM  :  NUMBER; 

NAMED  :  TOKEN  TYPE, 

POSITION  :  COUNT) 

is  separate; 

function  position__by_value  (list  :  list  type; 
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VALUE  :  NUMBER; 
START_POSITION: 

POSITION_COUNT : =  POSITION_COUNfFIRST; 

~  END  POSITION:  POSITION_COUNT 
:=  POSITION_COUNT*LAST) 
return  position_count  is  separate; 
end  I NTEGER_ITEM ; 
generic 

type  number  is  digits  <>; 
package  floatitem  is 

function  to_text(list_item:  number) 
return  string  is  separate; 


function  extract  (list  :  LiSTjnrE: 

POSITION  :  POSITION  COUNT) 
return  number 

is  separai  e : 

function  EXTRACT  (LIST  :  LIST  TYPE; 

NAMED  :  NAMESTRING) 
return  number 

is  separate; 

function  extract  (list  :  list_type; 

NAMED  :  TOKEN~ TYPE) 
return  NUMBER 


procedure  replace 


procedure  replace 


procedure  replace 


procedure  insert 


procedure  insert 


procedure  insert 


function  position 


is 

separate; 

(LIST 

.  in  out  LIST 

TYPE; 

LIST_ITEM  : 

NUMBER; 

POSITION 

POSITION  COUNT) 

is 

separate; 

(LIST 

;  in  out  LIST 

TYPE; 

LIST_ITEM  : 

NUMBER; 

NAMED 

NAME_STRING) 

is 

separate, 

(LIST 

:  in  out  LIST 

TYPE; 

LISTITEM  : 

NUMBER; 

NAMED 

TOKEN  TYPE) 

is 

separate; 

(LIST 

:  in  out  LIST_ 

TYPE; 

LIST  ITEM  : 

NUMBER; 

POSITION 

COUNT) 

is 

separate; 

(LIST 

:  in  out  LIST_ 

TYPE; 

LIST  ITEM  : 

NUMBER; 

NAMED:  NAME_STRING; 

POSITION  : "COUNT) 

is  separate; 

(LIST  :  in  out  L I ST_TYPE ; 

LIST_ITEM  :  NUMBER; 

NAMED  :  NAMESTRING; 
POSITION  :  COUNT) 

is  separate; 

BY_VALUE (LIST  :  LIST_TYPE; 

VALUE  :  NUmSeR; 


START_POSITION : 

POSITION_COUNT : =  POSITION_COUNT ’FIRST; 
END_POSITION: 

POSITION_COUNT:=  POSITION_COUNT’LAST) 
return  position_count 

is  separate; 

end  FLGAT_ITEM; 
package  stringitem  is 

function  extract  (L*JT  :  LIST_TYPE; 

POSITION  :  POSITION_COUNT) 
return  string 
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is  reparate; 

function  EXTRACT  (LIST  :  LIST  TYPE; 

MAMED  :  NAMF  STRING) 
return  STRING 

is  separate; 

function  EXTRACT  (LIST  ;  LIST  TYPE; 

NAMED  :  TOKEN_TYPE) 

return  string 


procedure  replace 


procedure  replace 


procedure  replace 


procedure  insert 


procedure  insert 


procedure  insert 


is 

separate; 

(LIST 

:  in  out  LIST  TYPE; 

LIST_ITEM 

STRING; 

POSITION 

POSITION_COUNT) 

is 

separate; 

(LIST 

:  in  out  LIST  TYPE; 

LIST_ITEM 

STRING; 

NAMED 

NAME  STRING) 

is  separate; 

(li  sr 

;  in  out  LIST  TYPE; 

LIST_ITEM 

STRING; 

NAMED 

TOKEN  TYPE) 

is  separate; 

(LIST 

;  in  out  LIST  TYPE; 

LISTITEM 

STRING; 

POSITION 

COUNT) 

is  separate; 

(LIST 

:  in  out  LIST  TYPE; 

LISTITEM 

STRING; 

NAMED 

NAMESTRING; 

POSITION 

COUNT) 

is  separate: 

(LIST 

:  in  out  LIST  TYPE; 

LIST_ITEM 

STRING . 

NAMED 

TOKEN  TYPE; 

POSITION 

COUNT) 

is  separate; 

function  positionbyvalue  (list  .  list  type; 

VALUE  :  STRING 

START_POSITION;  POSITION_COUNT 

:=  POSITION_COUNT'  FIRST; 
END_POSITION ;  POSITIONCDUNT 

:=  POSITION_COUNT 'LAST) 

return  position_count 

is  separate; 

end  STRING  ITEM; 


private 

type  TOKENTYPE  is  (IMPLEMENTATION  DEFINED)  ; 

—  should  bs  dafinsd  by  lsplassntor 

type  list_type  is  (implementation_defined)  ; 

—  should  bs  dsflnad  by  lsplsssntor 


end  LIST  UTILITIES; 
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Appendix  D. 

PACKAGE  LISTING  OF  CAIS  PROCEDURES  AND 
FUNCTIONS 


This  appendix  lists  the  CAIS  procedures  and  functions  in  the  context  of  their  assioiated  packages. 
This  appendix  is  intended  to  provide  a  simple  reference  to  the  CAIS  procedures  and  functions  in 
package  order. 


Operation 


Manipulation  of 
node  handles 


Querying  node 
kind  and  name 


Pathname  queries 


Node  queries 


Node  duplication 
interfaces 


Description  and  Interfaces 
Package  NODR _  MANAGEMENT 

The  following  Interfaces  are  used  for  manipulating 
node  handles  and  determining  node  handle  status  and 
node  handle  intent, 
procedure  OPEN 
procedure  CLOSE 
procedure  CHANGE_ INTENT 
function  IS  _  OPEN 
function  INTENT _OE 

The  following  interfaces  are  used  to  determine  the 
kind  of  a  node  (file,  process,  or  structural)  and 
the  primary  name  of  a  node, 
function  KIND 
function  PRIMARY _  NAME 

The  following  interfaces  allow  queries  about 
pathnames.  None  of  these  Interfaces  perform 
accesses  to  nodes;  they  perform  pathname 
manipulations  at  the  syntactic  level  only, 
function  PRIMARY_NAME 
function  PRIMAR Y_  KEY 
function  PRIMARY  RELATION 

function  PATH _ KEY 
function  PATH  RELATION 
function  BASE  _  PATH 
function  LAST _  RELATION 
function  LAST  _K  ICY 

The  following  Interfaces  allow  queries  about  nodes, 
function  IS  _ OBTAINABLE 
function  IS  SAME 
procedure  GET  _  PARENT 

The  following  interfaces  are  used  to  duplicate 
single  nodes  or  trees  of  nodes  spanned  by 
primary  relationships. 

procedure  ('OPY_NODE 
procedure  <  OPY_TREE 
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Alteration  of 
relationships 


Deletion  of  primary 
relationships 


Creation  and 
deletion  of 
secondary 
relationships 


Node  iterators 


Manipulation  of  the 
CURRENT  _NODE 
relationship 


Manipulation  of 
attributes 


The  following  interface  is  used  to  alter  the 
primary  relationship  of  a  node,  thereby  changing 
its  unique  primary  name. 

procedure  RENAME 

The  following  two  Interfaces  allow  the 
deletion  of  the  primary  relationship  of  a  single 
node  or  of  the  primary  relationships  of  a  node 
and  all  the  nodes  that  are  contained  in  the  tree 
spanned  by  primary  relationships  emanating  from 
these  nodes. 

procedure  DELETE _  NODE 
procedure  DELETE _ TREE 

The  following  Interfaces  allow  the  creation  and 
deletion  of  user-defined  secondary  relationships. 


procedure  LINK 
procedure  UNLINK 

The  following  interfaces  allow  the  iteration 
over  nodes  reachable  from  a  given  node  via  Its 
emanating  relationships. 

procedure  ITERATE 
function  MORE 
procedure  GET_NEXT 

The  following  interfaces  allow  changes  to 
the  relationship  of  the  predefined  relation 
CURRENT_NODE  emanating  from  the  current  process 
node  and  open  a  node  handle  on  the  node  that  is 
the  target  of  such  a  relatic  ship. 

procedure  SET  _  CURRENT  NODE 
procedure  GET_CURRENT_ NODE 

Package  ATTRIBUTES 

The  following  Interfaces  are  used  for  defining 
and  manipulating  the  attributes  for  nodes  and 
relationships. 

procedure  CREATE _  NODE _  ATTRIBUTE 
procedure  CREATE_  PATI I  _  ATTRIBl  ITE 
procedure  DELETE  _  NODE  ATTRIBl 'TE 
procedure  DELETE _ PATH  _  ATTRIBUTE 
procedure  SET_  NODE_  ATTRIBUTE 
procedure  SET  _  PATH  _  A  ^TRIBUTE 
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Manipulation  of 
access  control 


Creation  of 
structural  node 


Spawning  a 

process 


Awaiting  process 
termination 
or  abortion 


Invoking  a 
process 


Creating  a 
new  job 


examination  and 
modification  of 
results  list 


procedure  GET_  NODE_  ATTRIBUTE 
procedure  GET_ PATM_ ATTRIBUTE 
procedure  NODE_ATTRIBUTE_ ITERATE 
procedure  PATH  ATTRIBUTE  ITERATE 
function  MORE 
procedure  GET  _  NEXT 

Package  ACCESS  _  CONTROL 

The  following  interfaces  are  used  to  manipulate 
access  control  information  for  nodes. 

procedure  SET  _  ACCESS  _  CONTROL 
function  IS _ GRANTED 
procedure  ADOPT 
procedure  UNADOPT 

Package  STRUCTURAL  _  NODES 

The  following  interface  is  used  to  create  a 
structural  node  and  to  establish  the  primary 
relationship  to  It. 

procedure  CREATE  _  NODE 

Package  PROCESS _ CONTROL 

This  Interface  creates  a  process  node,  initiates 
the  new  process,  and  returns  control  to  the  calling 
task  upon  node  creation. 

procedure  SPAWN _ PROCESS 

This  interface  suspends  the  calling  task  and 
waits  for  the  process  to  terminate  or  abort. 

procedure  AWAIT_PROCESS_ COMPLETION 

This  Interface  is  functionally  the  same  as 
performing  a  call  to  SPAWN  _  PROCESS  followed 
by  a  call  to  AWAJT_ PROCESS_COMPLETION. 

procedure  INVOKE_ PROCESS 

This  interface  creates  a  new  root  process  node. 
Control  is  returned  to  the  calling  task  after 
the  new  Job  is  created. 

procedure  CREATE _  JOB 

These  Interfaces  provide  the  techniques  for  a 
process  to  examine  and  modify  a  results  list. 
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procedure  APPEND  _  RESULTS 
procedure  WR1TE_ RESULTS 
procedure  GET _ RESULTS 

Determination 
of  state  of 
process  and 
input  parameters 


Modification 
of  the  status 
of  a  process 


Handling  I/O 
and  time 
queries 

function  HANDLES  OPEN 
function  IO_  UNITS 
function  START_TfME 
function  FINISH _TIME 
function  MACHINE  TIME 


These  interfaces  are  used  to  determine  the  value 

of  the  predefined  attributes  CURRENT_STATUS  and 

PARAMETERS. 

function  STATE  _  OF  _  PROCESS 
procedure  GET  _ PARAMETERS 

These  interfaces  change  the  process  status  of  a 
process. 

procedure  ABORT  _  PROCESS 
procedure  SUSPEND _  PROCESS 
procedure  RESUME _  PROCESS 

These  Interfaces  are  used  to  query  process 
nodes  to  determine  the  values  of  the  predefined 
attributes  HANDLES _ OPEN,  IO-UNITS,  START  TIME, 
FINISH  TIME,  and  MACHINE  TIME. 


Packages  CAIS.DIRECT_  IO.  CAIS.SEQUENTIAL_  IO.  CAIS.TKXT_  IO 


Creating,  opening, 
and  deleting 
secondary  storage 
file 


Reading  and  writing 
characters  from/to 
text  file 


Setting  predefined 
relations 


These  Interfaces  are  used  to  create  a  file 
and  its  file  node,  to  open  a  handle  on  a 
file,  and  to  delete  a  file.  These  may  be 
used  with  direct  access,  sequential  access, 
and  text  files. 

procedure  CREATE 
procedure  OPEN 
procedure  DELETE 

Package  TKXT_IO 

This  procedure  is  used  to  read  and  write  characters 
from/to  a  text  file 


procedure  GET 
procedure  PUT 

These  interfaces  set  the  relationships  ol  i  lie 

prdeflned  relations  CURRENT  _  INPUT,  CURRENT_OU  i'l M  T. 
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and  CURRENT  ERROR. 

procedure  SET  _  INPUT 
procedure  SET  _  OUTPUT 
procedure  SET  __  ERROR 

These  interfaces  are  used  for  returning  an  open  file 
handle  on  the  error  file  and  for  returning  an  open 
file  handle  on  the  current  error  output  file. 

function  STANDARD _ ERROR 
function  CUR  RENT  _  ERROR 

Package  l<)_ CONTROL 

This  Interface  obtains  an  open  node  handle  from  a 
file  handle. 

procedure  OP  ;N_FILE_NODE 


This  interface  is  used  to  transmit  data  from  an 
Internal  file  to  Its  associated  external  file. 


procedure  SYNCHRONIZE 

These  interfaces  are  used  for  performing 
operations  on  log  files  and  for  handling 
prompt  strings,  character  arrays,  and 
function  keys. 

procedure  SET  _  LOG 
procedure  CLEAR _  LOG 
function  LOGGING 
function  GET_LOG 
function  NUMBER  _  OF _  ELEMENTS 
procedure  SET _  PROMPT 
function  GET  _ PROMPT 
function  INTERCEPTED  __  CHARACTERS 
function  ENABLED_ FUNCTION _ KEYS 
function  FUNCTION _  KEYS  _  ENABLED 

This  Interface  creates  a  queue  file  and  its  node. 

The  Initial  contents  of  the  queue  file  are  the 
same  as  those  of  the  file  to  which  it  is  coupled. 

The  queue  file  must  be  of  kind  MIMIC  or  COPY. 

procedure  COUPLE 

Package  SCROLL _ TERMINAL,  PAGE _ TERMINAL.  FORM _ TERMINAL 

Advancing  the  This  procedure  advances  the  active  position  to 


Creating 

coupled 

queue 


Handling  log 
nies,  prompts, 
and  function 
keys 


Transmitting 
data  from 
Internal  to 
external  file 


Opening  a 
file  node 


Opening  and 
returning 
handles  on 
error  files 
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active  position 


Querying  terminal, 
controlling  tab 
stop,  sounding 
bell  and  writing 
a  character 


Contolling  echo, 
querying  function 
keys  and  reading 
characters 
function  keys 


Line  and  page 
advancement 


Performing 
deletions,  orsisurcs, 
and  insertions  on 
a  page 
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it  j\m  \m  ins-. 


the  specified  position. 

procedure  SET_  POSITION 

Package  SCROLL _ TERMINAL,  PAGE_ TERMINAL 

These  interfaces  are  used  with  scroll  and  page 
terminals  to  determine  the  active  position, 
determine  terminal  row  and  column  size, 
manipulate  tab  stops,  sound  the  bell,  and 
write  a  character. 

function  GET  _  POSITION 
function  TERMINAL_  SIZE 
procedure  SET  _  TAB 
procedure  CLEAR _ TAB 
procedure  TAB 
procedure  RELL 
procedure  PUT 

These  interfaces  are  used  for  echoing  characters 
to  associated  output  devices,  determining  the 
maximum  allowable  function  key  identification 
numbcr.reading  a  character  or  characters,  and 
determing  information  about  function  keys. 

procedure  SET  _  ECHO 
function  ECHO 

function  MAXIMUM _ FUNCTION  KEY 

procedure  GET 

function  FUNCTION_KEY_COUNT 
procedure  FUNCTION _  KEY 
procedure  FUNCTION _KEY_  NAME 

Package  SCROLL _ TERMINAL 

These  Interfaces  are  used  to  control  line  and 
page  advancement. 

procedure  NEW_LINE 
procedure  NEW_PAGE 

Package  PAGE _ TERMINAL 

These  interfaces  are  used  for  deleting  characters 
characters  and  lines,  for  replacing  characters 
entire  displays  and  lines  with  spaces  and  for 
inserting  spaces  and  lines. 

procedure  DELETE  CHARACTER 
procedure  DELETE _ LINE 
procedure  ERASE _  CHARACTER 
procedure  ERASE _ IN _ DISPLAY 
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Graphic  rendition 
determination  and 
s<  lection 


Determing  maximum 
value  from 

TERMINATION  KEY 


Opening  form 
and  defining 
qualified  area 


Qualified  area 
advancement, 
writing,  and 
erasing 


Activating  form, 
reading,  and 
determining 
Information 
about  form 


Mounting,  status 
cheeking,  and 


procedure  ERASE_IN_LINE 
procedure  INSERT _SP ACE 
procedure  INSERT  _  LINE 

These  interfaces  are  used  for  determining  if  a 
graphic  rendition  is  supported  and  for  selecting 
a  particular  graphic  rendition. 

function  GKAPtllC_RENDnTON_SUI’l*ORT 
procedure  SELECT _ GRAPHIC _ RENDITION 

Package  FORM _ TERMINAL 

This  interface  returns  the  maximum  value  that 
may  be  returned  by  function  TERMINATION  _  KEY. 

function  MAXIMUM __ FUNCTION  _ KEY 

These  Interfaces  open  a  form  to  the  specified 
size,  determine  if  the  form  is  open,  define 
a  qualified  area,  and  remove  an  area  qualifier. 

procedure  DEFINE_QUALIFIED_ ARE \ 
procedure  REMOVE__  AREA  _  QUALIFIER 

These  Interfaces  advance  the  active  position  to 
a  subsequent  qualified  area,  write  to  a  form, 
erase  a  qualified  area,  and  erase  the  form. 

procedure  NEXT  _  QUALIFIED  _  AREA 
procedure  PUT 
procedure  ERASE  _  AREA 
procedure  ERASE_FORM 

These  interfaces  activate  the  form  on  the 
terminal,  read  data  from  the  form,  determine  If 
changes  have  been  made  to  the  form,  determine  the 
termination  key,  determine  the  size  of  the  form  and 
terminal,  and  determine  If  the  area  qualifier 
requires  space. 

procedure  ACTIVATE 
procedure  GET 

function  IS_ FORM _ UPDATED 
function  TERMINATION _KEY 
function  FORM  _  SIZE 
function  TERMINAL  SIZE 

function  AREA_QUALIFIER_REQUIRES_ SPACE 
Package  MAG NETIC_ TAPE 

Those  arc  used  to  load  un labeled  and  labeled 
tapes,  dismount  tapes,  determine  If  a  tape  is 
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writing  tape  loaded  or  mounted  and  where  It  is  positioned, 

marks  skip  tape  marks,  and  write  a  tape  mark. 


Initialize  and 
labeling  tapes 


Transferring 
flies  between 
CAIS  and  host 
system 


procedure  MOUNT 
procedure  LOAD  _  UNL ABELED 
procedure  LOAD  _  LABELED 
procedure  UNLOAD 
procedure  DISMOUNT 
function  IS  _  LOADED 
function  IS  _  MOUNTED 
function  TAPE  _  STATUS 
procedure  REW!ND_TAPE 
procedure  SKIP_TAPE_MARKS 
procedure  WRITE  _  T APE _  MARK 

These  interfaces  are  used  to  initialize  tapes,  to 
create  a  volume  file  holder,  end  of  file,  read  tape 
label  and  end  of  volume  label. 

procedure  IN!TL\LIZE_  UNLABELED 
procedure  INITIAUZE_  LABELED 
procedure  VOLUME _  HEADER 
procedure  FILE  _  HEADER 
procedure  END _FILE_ LABEL 
procedure  READ_  LABEL 
procedure  END_ OF  _  VOLUME 
procedure  RESET 

Package  FILE _  IMPORT _  EXPORT 

These  Interfaces  are  used  to  transfer  files 
between  a  CAIS  implementation  and  the  host 
file  system. 

procedure  IMPORT 
procedure  EXPORT 


Creation  and 
conversions  of 
lists 


Converting 
Identifiers 
and  tokens 


Package  LIST  _ UTILITIES 

These  Interfaces  are  used  for  converting  a  list 
from  an  external  to  internal  representation. 

procedure  TO  _  LIST 

These  interfaces  are  used  to  convert  an  identifier, 
which  is  a  list  Item  or  name  of  a  list,  to  a  token 
representation  and  a  token  representation  to  an 
identifier 

function  TO _ TOKEN 
function  IS  EQUAL 
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Extracting  and 
inserting 
subsets  of 
items 


Deleting  items 
from  a  list  and 
determining  list 
kind 


Determination  of 
kind  of  list  item 


Merging  lists 


Querying  list 
characteristics 


Manipulation  of 
items  in  a  list 


function  TO  IDENTIFIER 


These  Interfaces  are  used  to  extract  a  subset  of 
items  from  a  list  and  to  insert  a  subset  of  items 
into  a  list. 

procedure  SPLICE 
function  SET _  EXTRACT 

These  interfaces  are  used  to  delete  an  Item  from 
a  list  and  to  determine  the  kind  of  list. 


procedure  DELETE 
function  GET _  LIST  _ KIND 

This  Interface  is  used  to  determine  the  kind 
of  list  item. 

function  GET_ITEM_KIND 
This  Interface  is  used  to  merge  two  lists, 
procedure  MERGE 

These  interfaces  are  used  to  determine  the  nui  iber 
of  Items  in  a  list,  the  name  of  a  list  item  in  a 
named  list  and  the  position  of  a  named  item. 

function  LENGTH 
function  TEXT  _  LENGTH 
procedure  ITEM_NAME 
function  POSITION _BY_  NAME 

Package  LIST _ UTILITIES,  INTEGER  _  ITEM.  FLOAT _ITKM. 
IDENTIFIER  _ ITEM,  STRING  _  ITEM 

These  interfaces  are  used  to  manipulate  Integer 
Items,  floating  point  Items,  identifiers  represented 
as  tokens  lists,  and  strings  that  are  in  a  list. 

function  TO  _  TEXT 
procedure  EXTRACT 
procedure  REPLACE 
procedure  INSERT 
function  POSITION  HY_ VALUE 
procedure  TO _ TOKEN 
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Exception*  useful  for  node  manipulation.*  31 

Existence  of  the  nodr  33 

EXPORT  190 

External  file  7.  103 

EXTRACT  204.  207.  210.  213 

File  7 

File  handle  7.  103 

File  nodr  7.  13.  M 

fllr  transfer  189 

FILE  _  HEADER  185 

FILE  _  KIND  101 

FILE  _STR!NG  175 

FILE  .TYPE  113.175 

FINISH  _TIMF.  99 

Form  7.  1 1 1 

Form  terminal  101 

FORM_*IZE  172 

FORM  .STRING  32.77 

FORM  .TYPE  188 

FL’NCTION.KEY  Ml.  158 

Fl.NCTION.KEY.COl  NT  Ml.  158 

FUNCTION  _  KEY  _  DESCRIPTOR  14-5 

FCNCTION  XEY.NAME  M2.  187 

FVN<  TION  _ KEYS _ ENABLED  128 

GET  118.  139.  MO.  151.  155.  17 1 
GET.Cl  RRENT.NODE  81 
GET  _  LIST  _  KIND  198 
GET_LOG  123 
GET_NEXT  59.73 
GET.NODE.ATTRIBCTE  89 
GET_  PARAMETERS  92 
GET_  PARENT  47 
GET  _PATH  .ATTRIBUTE  89 
GET_POSITION  131.  M8 
GET  _  PROMPT  125 
GET.RESCLTS  90 
GRANT  21 

GRAPHIC  _  RENDITION  _  ARRAY  145 
GRAPHIC  _  RENDITION  _ ENUMERATION  M5 
GRAPHIC  _ RENDITION  _S1  PPORT  184 
Group  7.  22 

HANDLES  OPEN  98 
Hierarchical  classification  level  28 
HIGHEST  .C  LASSIFICATION  28 

Identification  18 

Illegal  Identification  7.  18 

IMPORT  189 

IN.FILE  144.  148 

Inaccessible  7.  20 

INITIALIZE.  LABELED  178 

INITIALIZE  INLABKI.KD  177 

Initiate  7 

Initiated  13 

Initiated  prt>ct— s  7.  13 

Initiating  prorcs*  7.  13 

INOt  T  .  FILE  Ml 

Input  and  output  100 

INSERT  202.  205.  208.  211.  214 

INSERT  LINE  183 
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INSERT  _  SPACE  182 

INTENT  21.  33 

INTENT  _  OF  31 

INTENT  _  SPECIFICATION:  32 

INTENT  _  VIOLATION  32 

INTENTION  37 

INTERCEPTED  _  CHARACTERS  125 
Interface  7 
Internal  file  7.  103 
Invoke  80 

INVOKE  _  PROCESS  33.85 

IO_  DEFINITIONS  KM 

IO_l'NITS  97 

1S_  FORM  _  I’PDATED  171 

IS  _  GRANTED  75 

IS  _  LOADED  180 

IS  _  MOUNTED  181 

IS  _  OPEN  31 

IS  _  SAME  36 

ITEM  _  NAME  199 

ITERATE  58 

Iteration  status  72 

Iterator  7 

Job  7.  15.  16 

Key  7.  IS 

Keyword  member  27 
Keywords  27 
KIND  31.  191.  196 

Label  173 
Label  (roup  7.  183 
LAST_KEY  35 
LAST  _  RELATION  35 
Latest  key  8.  1 7 
LATEST _ KEY  17.  77 
LA  YOlT_  ERROR  135 
LENGTH  198 
LEVEL  113 
LINK  35 
List  8.  191 

List  classifications  191 

List  Item  8.  191 

LIST  _  TYPE  62.  63.  63.  65 

LOAtT_  LABELED  177 

LOAD  _  L’NLABF.LED  176 

LOCK  _  ERROR  32 

Locked  afnlnst  read  operations  33 

Locks  on  the  node  33 

LOGGING  123 

LOWEST  C  LASSIFICATION  28 

MAI  IIINE_TIMK  100 
Macneflr  tape  drive  file  100.  101 
Mandatory  arrest,  control  8.  19.  26 
Manipulation  of  attributes  62 
MAXIMlM_FlNCTION_KEY  153.  167 
M.VNIMl'M_Fl  NOTION _ KEYS  138 
MERGE  197 
Mimic  queue  101.  120 
MODE_ERROR  115 
Modify  node  attributes  33 


Page  3-386 


312 


PROPOSED  \HL-'TD-(  \|S 
3!  J.ANTARY  1085 


MORE  59.  72 
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Named  Ms-  8 
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NEW  LIVE  I  13 

NEW  PU.E  III 

NEXT_Qr.MJFIKD_.AREA  180 

NO  _  DELAY  32 

Node  8.  13 

Node  attributes  82 

Node  handle  8.  31 

Node  management  31 

NODE  _ATTRIBITE_  ITER  ATE  71 

NODE  _  DEFINITIONS  31 

NODE  _  ITERATOR  37.  58 

NODE  _  KIND  32.58 

NODE _ MANAGEMENT  31.  33 

NODE  _  TYPE  31.  15 
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Page  terminal  101 
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POTENTIAL  .MEMBER  22 
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Precede  1 30 
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Predefined  relations  15,  80 

Primary  relationship  9.  15 

PRIMARY  KEY  12 

PRIMARY  _  NAME  12 

PRIMARY  _  RELATION  13 

PR  INTAHLK_  CHARACTER  169,  171 

PRINTABI.E  t  IIAKACTKIt*  166 

PRIYII,KC,K_S|>F.(  IKK  ATION  71 
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Postscript  :  Submission  of  Comments 

For  submission  of  comments  on  this  proposed  MIL-STD-CA1S,  we  would  appreciate  them  being  sent 
by  ARPANET/MILNET  to  the  address 

CAJS-COMMENT  at  ECLH 

If  you  do  not  have  Arpanet  access,  please  send  the  comments  by  mail 

Patricia  Oberndorf 

Naval  Ocean  Systems  (  enter 

Code  423 

San  Diego,  CA  92152-5000 

For  mail  comments,  it  will  assist  us  if  you  are  able  to  send  them  on  8-inch  single-sided  single-density 
DEC  format  diskette  -  but  even  if  you  can  manage  this,  please  also  send  us  a  paper  copy,  in  case  of 
problems  with  reading  the  diskette. 

All  comments  are  sorted  and  processed  mechanically  in  order  to  simplify  their  analysis  and  to 
facilitate  giving  them  proper  consideration.  To  aid  this  process  you  are  kindly  requested  to  precede 
each  comment  with  a  three  line  header 

Isection  ... 

Iverslon  MIL-STD-OAIS 
Itoplc  ... 

!rationale  ... 

The  section  line  Includes  the  section  number,  the  paragraph  number  enclosed  In  parentheses,  your 
name  or  affiliation  (or  both),  and  the  date  in  ISO  standard  form  (year-month-day).  As  an  example, 
here  Is  the  section  line  of  a  comment  from  a  previous  version: 

! section  03.02.0l(l2)A.  Gargaro  82-04-28 

The  version  line,  for  comments  on  the  current  document,  should  only  contain  "MIIy-STI)-CAIS".  Its 
purpose  Is  to  distinguish  comments  that  refer  to  different  versions. 

The  topic  line  should  contain  a  one  line  summary  of  the  comment.  This  line  is  essential,  and  you  are 
kindly  asked  to  avoid  topics  such  as  "Typo"  or  "Editorial  comment"  which  will  not  convey  any 
Information  when  printed  In  a  table  of  contents.  As  an  example  of  an  informative  topic  line,  consider: 

Itoplc  FILE  NODE  MANAGEMENT 

Note  also  that  nothing  prevents  the  topic  line  from  Including  all  the  Information  of  a  comment,  as  In 
the  following  topic  line: 

Itoplc  Insert:  "...are  {implicitly}  defined  by  a  subtype  declaration" 

As  a  final  example  here  Is  a  complete  comment: 

I  section  03.02.01(!2)A.  Gargaro  85-01-15 

Iverslon  MIl^STD-CAIS 

Itoplc  FILE  NODE  MANAGEMENT 

Change  "component"  to  "subcomponent"  In  the  last  sentence. 

Otherwise  the  statement  Is  inconsistent  with  the  defined  use  of  subcomponent  In  3.3,  which  says  that 
subcomponents  are  excluded  when  the  term  component  Is  used  instead  of  subcomponent. 
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INSTRUCTIONS:  In  a  continuing  tffort  to  maha  our  umliwUiitioa  document!  better,  tha  Do 0  provide*  thu  form  for  uaa  in 
•ubmitting  rnmmann  tad  auggastiona  for  improvement*.  All  uaati  of  military  atandardiaatton  docu  manta  an  in  at  tad  to  provide 
mggaationa.  Thia  form  may  bo  detached,  foldad  alone  tha  liaaa  indicated,  tapod  alone  tha  looaa  adf*  (DO  NOT  STAPLE) ,  and 
mailad  la  block  6,  be  aa  apecific  aa  poaaiblc  about  particular  problem  area#  auch  aa  wording  which  required  interpretation,  waa 
too  rigid,  fcatrictiio,  looaa,  ambiguoua,  or  waa  incompatible,  and  give  ptopoaad  wording  changaa  which  would  alleviate  tha 
problaow.  Enter  in  block  6  any  remarka  not  related  to  a  (pacific  paragraph  of  tha  document.  If  block  7  ia  filled  out,  an 
acknowledgement  will  be  mailed  to  you  within  30  daya  to  let  you  know  that  your  commenta  were  received  and  are  being 
oonriderari. 

NOTE:  Thia  form  may  not  be  uaed  to  requaat  copica  of  docu  manta,  nor  to  requaat  waiver  a,  deviation*.  or  clarification  of 
apedfleation  requirement*  on  current  contra  eta.  Commenta  aubmitted  on  thia  form  do  not  constitute  or  imply  authorisation 
to  waive  any  portion  of  tha  referenced  documentfs!  or  to  amend  contractual  requirementa. 
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Commander 

Naval  Ocean  Systems  Center 
San  Diego,  CA  92152 
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Grumman  Aerospace 
Corporation 


January  2,  198S 


Patricia  Obemdorf 
Naval  Ocean  Systems  Center 
271  Catalina  Blvd 
San  Diego,  CA  92152 

Dear  Tricia: 

Enclosed  is  a  copy  of  the  CAIS  Standards  Coordination  Report, 
submitting  it  for  publication  in  the  next  KITIA  Public  Report. 


krr 


Enclosure 


Bemie  Abrams 


I  am 
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INTRODUCTION 

This  report  contains  a  summary  and  analysis  of  standards  and 
specifications  that  could  possibly  conflict  with  CAIS.  A  list  of 
applicable  standards  was  obtained  from  various  indexes  and  by 
asking  knowledgeable  people.  The  primary  index  used  was  DODISS 
(Department  of  Defense  index  of  Standards  and  Specifications). 
Both  government  and  industry  standards  were  examined.  Standards 
that  were  suspected  of  conflicting  or  of  being  redundant  with 
CAIS  were  read  and  are  reported  herein. 

DISCUSSION 

A  summary  of  the  pertinent  information  on  each  standard 
examined  is  in  the  body  of  this  report.  The  summary  contains 
identification  of  the  standard,  a  short  abstract,  and  a 
discussion  of  the  connection  to  CAIS.  An  index  on  the  next  page 
lists  all  the  standards. 

This  report  would  not  have  been  possible  without  the 
assistance  of  the  Grumman  Aerospace  Corp.  Engineering  Standards 
Department . 

CONCLUSION 

Standards  that  should  be  examined  for  possible  overlap  are: 

OSCRL  (Operating  System  Command  and  Response  Language) 

DOD  STD  1467  Software  Support  Environment 

There  are  other  standards  that  specify  the  way  a  standards 
document  is  formatted  or  the  quality  control  of  a  program.  These 
must  be  considered  in  making  CAIS  a  standard,  but  have  no  direct 
conf 1 ict . 
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DETAIL  DESCRIPTION 


DOCUMENT  ID:  ANSI/ANS  10.2  1982 

TITLE  Recommend  Programming  Practices  to  Facilitate 

the  Portability  of  Scientific  Computer  Programs 

DOCUMENT  DATE  12  March  1982 

AGENCY  American  Nuclear  Society 

STATUS  Approved 

SUMMARY  Programming  practices  are  recommended  for 

making  application  programs  portable.  The  emphasis  is  on 
scientific  and  engineering  applications  in  FORTRAN.  Typical 
recommendations  are  to  avoid  extensions  to  ANSI  Fortran. 

CONNECTION  TO  CAIS  There  is  no  connection.  ANSI  10.2  is 
concerned  with  achieving  portability  by  using  a  common  subset 
of  a  variety  of  FORTRAN  versions.  CAIS  achieves  portability 
by  standardizing  on  an  operating  system  interface  in  an 
environment  where  the  programming  language  is  standard. 

REVIEW  DATE  9  July,  1984 


DOCUMENT  ID:  ANSI/ANS  10.5  1979 


TITLE  Guidelines  for 

Computer  Program  Development 


Considering  User  Needs  in 


DOCUMENT  DATE 

AGENCY 

STATUS 


29  August,  1979 
American  Nuclear  Society 
Approved 


SUMMARY  User  concerns  are  listed  including  proper 

application,  ease  of  use,  reliability,  and  time  required  to 
obtain  results.  Design  practices  to  achieve  programs  that 
meet  the  users  concerns  are  modularity,  automated  adjustment 
to  hardware  differences,  and  minimized  input  by  using  default 
values. 


CONNECTION  TO  CAIS  This  standard  is  a  good  summary  of  design 
pract i ces  Tor  building  user  friendly  programs,  but  it  is  not 
directly  applicable  to  CAIS  because  CAIS  does  not  define  a 
human  user  interface. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  ANSI  X3H1 

TITLE  OSCRL  (Operating  System  Command  <$c  Response 

Language)  Specification  09SD 


DOCUMENT  DATE  2  February  1984  Revision  20 


AGENCY  ANSI 

STATUS  Draft 


SUMMARY  OSCRL  specifies  the  command  language  used  by  a 

human  user  to  request  operating  system  services.  The  purpose 
is  to  promote  portability  of  people  and  programs  among 
general  purpose  computer  systems.  OSCRL  has  commands  for 
managing  files  (COPY,  CREATE,  DELETE),  corrmands  for  managing 
processes  (SUBMIT),  and  a  procedural  language  for  controlling 
corrmands  (IF,  LOOP,  GO  TO,  EXIT). 


CONNECTION  TO  CAIS  There  is  a  strong  connection  between  CAIS 
and  OSCRL.  CAIS  specifies  the  language  used  by  a  computer 
program  to  call  for  operating  system  services.  These  are  the 
same  services  that  a  human  user  requests  with  OSCRL.  The  two 
languages  should  be  compatible.  If  both  specifications  are 
adopted,  then  a  user  will  use  OSCRL  to  enter  requests  which 
will  be  translated  by  a  command  interpreter  to  CAIS  calls. 

There  have  been  discussions  of  having  the  user  enter 
commands  in  Ada.  The  OSCRL  language  is  not  Ada. 

There  is  a  definite  need  to  coordinate  OSCRL  and  CAIS 
since  they  overlap  in  many  areas.  One  example  is  file  naming 
conventions.  A  detailed  comparison  of  the  OSCRL  draft  with 
CAIS  should  be  prepared. 
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DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 
AGENCY 
STATUS 
SUMMARY 


ANSI/MIL-STD  1815A 
Ada  Programming  Language 
22  January  1983 

Ada  Joint  Programming  Office,  DoD 
Approved 

Ada  Language  Reference  Manual 


CONNECTION  TO  CAIS  In  addition  to  the  requirement  that  CAIS 
conform  to  the  Ada  language,  MIL-STD  1815A  is  a  prototype  of 
the  format  for  CAIS.  For  example  the  precedent  of  allowing  an 
exception  to  the  outline  of  MIL-STD  962  was  set  by  MIL-STD 
1815A  and  followed  by  CAIS. 

REVIEW  DATE  9  July,  1984 


DOCUMENT  ID:  DoD  4120. 3-M 


TITLE  Defense  Standardization  and  Specification 

Program,  Policies,  Procedures  and  Instructions 

DOCUMENT  DATE  July,  1980 

AGENCY  DoD 


STATUS  Mandatory  for  use  by  all  DoD  activities 

SUMMARY  The  organizational  procedure  for  making 

standards  is  described.  It  includes  organization  and 
assignments,  planning,  programming,  policies  and  procedures 
for  standardizing  documents. 


CONNECTION  TO  CAIS  The  procedure  for  making  CAIS  a  standard 
is  described  here. 


REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID;  DOD-STD  7935 

TITLE  Automatic  Data  System  (ADS)  Documentation 

DOCUMENT  DATE  13  September  1977 

AGENCY  Department  of  Defense 

STATUS  Approved 

SUMMARY  All  the  documents  that  must  be  produced  when 

developing  a  computer  system  are  describe.  Standard  outlines 
are  given. 

CONNECTION  TO  CAIS  An  implementation  of  CAIS  would  be  an  ADS, 

but  CAIS  itself  is  not.  It  might  be  considered  an  FD 
(Functional  Description)  which  is  one  of  the  documents  of  the 
development  life  cycle  required  by  DOD-STD  7935. 

REVIEW  DATE  9  July,  1984 


DOCUMENT  ID:  FIPS  PUB  30 

TITLE  Software  Sunmary  for  Describing  Computer 

Programs  and  Automated  Data  Systems 

DOCUMENT  DATE  30  June  1974 

AGENCY  Institute  for  Computer  Science,  NBS 

STATUS  Approved 

SUMMARY  This  publication  provides  a  standard  software 

sunmary  form  (SF-185)  for  describing  computer  programs  and 
automated  data  systems  for  identification,  reference,  and 
dissemination  purposes. 

CONNECTION  TO  CAIS  none 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID: 


FIPS  PUB  41 


TITLE 


Computer  Security  Guidelines  fc 


the  Privacy  Act  of  1974 
DOCUMENT  DATE  30  May,  1975 

AGENCY  National  Bureau  of  Standards 

STATUS  Approved 

SUMMARY  This  is  general  guidelines 

security  including  physical  security,  entry 
encryption,  and  programming  practices. 

CONNECTION  TO  CAIS  Nothing  in  CAIS 

implementation  of  the  security  provisions  of  F 

REVIEW  DATE  9  July,  1984 


r  Implementing 


for  computer 
controls,  data 


prevents  the 
IPS  PUB  41. 
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DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 
AGENCY 


FIPS  PUB  46 

Data  Encryption  Standard 
15  January  1977 

Institute  for  Computer  Science,  NBS 


STATUS  Approved 

SUMMARY  An  algorithm  is  described  for  enciphering  and 

deciphering  a  block  of  data.  The  algorithm  is  applied  to  data 
when  it  leaves  a  system,  and  again  when  it  reenters  the 
system.  The  implementation  method  is  not  described.  Whether 
or  not  the  encryption  is  done  in  the  CPU  or  in  separate 
modules  is  not  specified. 


CONNECT  ION  TO  CAIS  Encryption  translates  a  given  bit  pattern 
into  a  random  pattern.  Therefore  the  transmission  system 
after  the  point  of  encryption  must  pass  all  bit  combinations. 
Any  CAIS  feature  that  prevents  the  transmission  of  specific 
characters  could  interfere  with  encryption. 


REVIEW  DATE  9  July,  1984 


DOCUMENT  ID:  IEEE  162-63 

TITLE  Standard  Definition  of  Terms  for  Electronic 

Digital  Computers 

DOCUMENT  DATE  Dec  63 

AGENCY  IEEE 

STATUS  Approved 

SUMMARY  This  is  a  hardware  oriented  glossary. 

CONNECTION  TO  CAIS  Possible  use  in  definitions. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  IEEE  STD  730-81 

TITLE  Standard  for  Software  Quality  Assurance  Plans 

DOCUMENT  DATE  1981 

AGENCY  IEEE 

STATUS  Approved 

SUMMARY  This  standard  describes  what  a  SQAP  (Software 

Quality  Assurance  Plan)  should  be.  A  SQAP  applies  to  a 
software  development  project.  The  activities  and  documents 
needed  for  QA  are  listed.  The  minimum  activities  are  SRR 
(Software  Requirements  Review),  PDR  (Preliminary  Design 
Review),  CDR  (Critical  Design  Review),  SVR  (Software 
Verification  Review),  Functional  Audit,  Physical  Audit,  and 
In  Process  Audit.  The  minimum  documents  are  SRS  (Software 
Requirements  Specification),  SDD  (Software  Data  Design)  SVP 
(Software  Verification  Plan)  and  SVR  (Software  Verification 
Report ) . 

CONNECTION  TO  CAIS  The  CAIS  itself  is  an  interface  standard, 
not  executable  software,  and  therefore  is  not  subject  to  the 
same  QA  requirements  as  a  software  product.  However,  CAIS  is 
a  product  and  as  such  should  have  some  QA  plan.  A  CAIS 
implementation  is  software  and  needs  a  full  QA  plan. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  MIL  S  52779A 

TITLE  Software  Quality  Assurance  Program  Requirements 

DOCUMENT  DATE  1  August,  1979 

AGENCY  US  Army  Computer  Systems  Conmand 

STATUS  Approved  by  Department  of  Defense 

SUMMARY  This  standard  is  applicable  to  computer 

programs  and  related  data  and  documentation.  A  Software 
Quality  Assurance  Program  is  described.  Included  is  the 
requirement  for  practices  and  procedures  to  assure 
compliance.  In  addition  the  tools,  techniques,  and 

methodologies 

CONNECT  ION  TO  CAIS  An  implementation  of  CAIS  will  require  a 
QA  program. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  MIL-STD  1 2D 

TITLE  Abbreviations  for  Use  on  Drawings,  and  in 

Specifications,  Standards,  and  Technical  Drawings. 

DOCUMENT  DATE  29  May  1981 

AGENCY  Department  of  Defense 

STATUS  Approved 

SUMMARY  This  standard  contains  a  list  of  approved 

abbreviations  for  use  in  specifications  and  standards.  The 
list  is  by  the  full  spelling  and  is  cross  referenced  by 
abbreviation.  An  interesting  quote  is  "when  in  doubt,  spell 
it  out". 

CONNECTION  TO  CAlSAbbr e v i a t i ons  in  CAIS  should  not 
contradict  MIL-STD  12D.  An  abbreviation  such  as  "CAIS"  that 
is  too  specific  to  appear  in  MIL-STD  12D  is  acceptable. 

The  approved  abbreviation  for  Identification  is  IDENT. 
The  use  of  ID  in  the  CAIS  text  violates  MIL-STD  12D.  A  non¬ 
standard  abbreviation  may  be  used  in  a  computer  name. 
Agreement  between  computer  names  and  MIL-STD  12D  is  optional. 
The  standard  is  concerned  with  abbreviations  in  text. 

REVIEW  DATE  9  July,  1984 


DOCUMENT  ID:  MIL-STD  483 

TITLE  Configuration  Management  Practices  For  Systems, 

Equipment,  Munitions,  And  Computer  Programs 

DOCUMENT  DATE  1  June  1971 

AGENCY  USAF 

STATUS  Approved 

SUMMARY  This  is  one  of  several  standards  for 

configuration  management. 

CONNECT  ION  TO  CA  IEh  i  s  will  be  important  during 
impl ementat i on . 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  MIL  STD  961A 

TITLE  Military  Specification,  Preparation  Of 

DOCUMENT  DATE  22  September  1981 

AGENCY  DoD 

STATUS  Approved 

SUMMARY  The  format  of  a  MIL  Specification  is  described. 

The  use  if  "will"  and  "shall",  the  standard  section 
numbering,  style  and  word  usage  are  specified. 

CONNECTION  TO  CAI S  CAIS  is  a  standard,  not  a  specification.  A 
companion  document,  MIL  STD  962  applies  to  CAIS. 

REVIEW  DATE  9  July,  1984 


DOCUMENT  ID;  MIL  STD  962 

TITLE  Outline  of  Forms  and  Instructions  for  the 

Preparation  of  Military  Standards 

DOCUMENT  DATE  22  September,  1975 

AGENCY  DoD,  Defense  Electronics  Supply  Center 

STATUS  Approved 

SUMMARY  This  standard  gives  the  format  of  a  MIL 

Standard  including  word  usage,  paragraph  identification, 
symbols,  format  for  tables,  use  of  footnotes,  and  figure 
sizes.  A  standardized  outline  is  described. 


CONNECTION  TO  CAIS  MIL  STD  96  2 
does  conform  Tn  terms  of  format 
not  follow  the  standard  outline, 
because  the  standard  outline 


is  applicable  to  CAIS.  CAIS 
and  style.  However  CAIS  does 
This  exception  is  necessary 
does  not  fit  an  interface 


definition  like  CAIS. 
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DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 


MIL-STD  1644 

Trainer  System  Software  Development 
7  March  1979 


AGENCY  Naval  Trainer  Equipment  Center 

STATUS  Approved 


SUMMARY 

procedure 
1679  and 
procedures 


This  is  o 
for  developing 
MIL  STD  SDS . 
to  be  followed 


le  of  several 
software.  The 
The  documents 
are  specified. 


standards 
others  are 
requ i red 


on 

MIL 

and 


the 

STD 

the 


CONNECTION  TO  CAIS 


None  since  CAIS  is  not 


training  equipment 


REVIEW  DATE  9  July,  1984 


DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 
AGENCY 


MIL-STD  1679 

Weapon  System  Software  Development 
1  December  1978 
NAVMAT  09Y 


STATUS  Approved 

SUMMARY  This  standard  controls  the  way  software  is 

developed  with  emphasis  on  documents  and  procedures. 


CONNECTION  TO  CAIS  Weapon  System  software  is  defined  broadly 
enough  to  i nclude  software  development  facilities  of  which 
CAIS  is  a  part.  An  implementation  of  CAIS  should  follow  one 
of  the  software  development  standards. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID: 


MIL- STD  SDS 


TITLE  Defense  System  Software  Development 

DOCUMENT  DATE  20  December  1983 


AGENCY 


USAF  RADC 


STATUS  Draft  Not  Approved 

SUMMARY  The  methods  and  documents  for  software 

development  are  specified.  Structured  programming  constructs 
are  required.  This  standard  is  a  replacement  for  MIL-STD  1679 
and  MIL-STD  1644. 


Important  quotes  are  "the  contractor  is  encouraged  to 
incorporate  cormerci  al  ly  available  software"  and  "the 
contractor  shall  produce  code  that  can  be  regenerated  and 
maintained  using  only  government-owned  or  contractually 
deliverable  software." 

CONNECTION  TO  CAIS  There  is  no  conflict.  This  Standard 
controls  the  way  CAIS  is  implemented. 

REVIEW  DATE  9  July,  1984 
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DOCUMENT  ID:  ANSI  X3. 102-1983 

TITLE  Data  Cormuinicat  ion  Systems  and  Services  -User 

Oriented  Performance  Parameters 

DOCUMENT  DATE  22  February,  1983 

AGENCY  ANSI  -  Computer  and  Business  Equipment 

Manufacturers  Association 

STATUS  Approved 

SUMMARY  The  standard  defines  21  data  communication 

performance  parameters.  These  parameters  quantify  the  quality 
of  service  that  a  communication  system  gives  a  user.  A  user 
can  be  a  human  operator  or  an  application  program. 

Some  of  the  parameters  defined  are  access  time, 
incorrect  access  probability,  access  denial  probability, 
block  transfer  time,  block  error  probability,  block  loss 
probability,  and  user  information  bit  transfer  rate.  No 

target  values  are  given  for  any  of  the  parameters. 


CONNECTION  TO  CAIS  This  specification  is  important  in 
evaluat i ng  a  CAIS  Tmpl ementat i on  for  performance.  Generally 
performance  of  an  operating  system  is  measured  in  terms  of  a 
vaguely  defined  parameter  like  response  time.  ANSI  x3.102  gives 
rigorouslv  defined  performance  parameters. 

REVIEW  DATE  17  September  1984 
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DOCUMENT  ID:  FIPS  PUB  20  (ANSI  X10. 1-1973) 

TITLE  Guidelines  for  Describing  Information 

Interchange  Formats 

DOCUMENT  DATE  1  March  1972 

AGENCY  National  Bureau  of  Standards  Center  for 

Computer  Science. 

STATUS  Approved  and  adapted  by  ANSI 

SUMMARY  Information  is  collected  or  interchanged  by 

manual  forms,  mark  sense  forms,  moveable  machine  sensible 
media  (cards,  tapes,  disks),  direct  on-line  entry,  or  direct 
online  interchange  between  computers.  Usually  there  are  three 
places  where  information  is  described  -  on  an  external  label, 
on  a  machine  readable  label,  and  in  a  document  that 
accompanies  the  information.  This  specification  is  a 

checklist  of  the  information  that  goes  into  the  description. 

CONNECTION  TO  CAIS  There  is  no  direct  connection.  This 
document  should  be  considered  in  any  implementation  that  has 
to  achieve  interoperability  of  data.  Compatible  descriptions 
are  needed  to  transport  data. 

REVIEW  DATE  17  September  1984 
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DOCUMENT  ID;  DOD-STD  1467 

TITLE  Software  Support  Environment 

DOCUMENT  DATE  1  May,  19  84 

AGENCY  AMCCOM 

STATUS  Proposed 

SUMMARY  This  standard  establishes  minimum  requirements 

for  the  contractor  to  define  a  software  development  support 
environment  to  ensure  compatibility  with  a  contracting 

activity's  designated  life  cycle  software  support 
environment.  It  is  used  with  DOD-STD  1679A.  The  contractor 

shall  ensure  and  warrant  the  existence  of  a  capability  of  the 

contracting  agency  to  perform  software  support. 

CONNECTION  TO  CAIS  DOD-STD  1467  implies  that  if  the 
Government  uses  CAIS  for  software  support,  the  contractor 

must  warrant  that  CAIS  can  be  used  by  the  services  for 
maintenance.  The  contractor  need  not  use  CAIS  if  he  can  prove 
that  CAIS  can  support  systems  developed  on  the  contractors 
envi ronment . 

REVIEW  DATE  21  September  1984 
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DOCUMENT  ID: 
TITLE 

DOCUMENT  DATE 

AGENCY 

STATUS 

SUMMARY 

federal  s 
cop i ed . 


FIPS  PUB  79  (ANSI  X3. 27-1078) 

Magnetic  Tape  Labels  and  File  Structure 
17  October,  1980 
National  Bureau  of  Standards 
Approved 

FIPS  PUB  79  establishes  ANSI  X3. 27-1078 
tandard.  ANSI  X3. 27-1978  is  referenced  and 


as  a 
not 


CONNECTION  TO  CAIS  See  ANSI  X3. 27-1978 
REVIEW  DATE  21  September  1984 


DOCUMENT  ID:  ANSI  X3. 27-1978 


TITLE  Magnetic  Tape  Labels  and  File  Structures  For 

Information  Interchange 

DOCUMENT  DATE  18  April 

AGENCY  Institute  for  Computer  Sciences  and  Technology, 

American  National  Standards  Institute,  Inc. 


STATUS  Approved 

SUMMARY  The  purpose  is  to  standardize  tape  label 

formats  so  that  tapes  of  different  systems  can  be 
interchanged.  The  format  of  tape  labels  are  defined  in 
detail.  Included  are  volume  headers,  user  volume  headers, 
file  labels,  and  end  of  file  labels.  The  position  and  format 
of  each  field  in  a  label  is  defined. 


CONNECTION  TO  CAIS  There  is  no  conflict.  The  exchange  of  data 
between  systems  (interoperability)  requires  standardi zat ion 
on  many  levels.  CAIS  standardizes  at  an  abstract  level,  the 
calls  from  an  application  program  to  a  system  10  package. 
ANSI  X3.27  standardizes  at  a  more  physical  level,  the  tape 
labels.  An  implementation  of  CAIS  must  accept  tapes  with  ANSI 
X3.27  labels. 


REVIEW  DATE  24  September  1984 


Page  3-414 


CAIS  Standards  Coordination  Report 


Page  20 


DOCUMENT  ID; 
TITLE 

DOCUMENT  DATE 
AGENCY 


ANSI  X3. 66-1979 

Advanced  Data  Communication  Control  Procedures 

9  January,  1979 

ANSI-CBEMA 


STATUS  submitted  for  approval 

SUMMARY  Data  communication  control  procedures  define 

the  means  for  exchanging  data  between  business  machines  over 
communication  circuits.  The  advanced  data  communication 
control  procedures  (ADCCP)  described  are  synchronous  and  bit 
or i ented . 


CONNECT  ION  TO  CAIS  none.  Both  CAIS  and  ANSI  X3.66  are 
standards  needed  to  insure  interoperability  of  data,  but  the 
two  standards  address  different  levels.  ANSI  X3.66 
standardizes  the  bit  stream  interchange  protocol.  CAIS 
standardizes  operating  system  calls.  Standardization  at  both 
levels  is  needed  for  interoperability. 

REVIEW  DATE  24  September  1984 


DOCUMENT  ID: 


IEEE  STD  696-1983 


TITLE  Interface  Devices 

DOCUMENT  DATE  10  July,  1982 


AGENCY  IEEE 

STATUS  Approved 

SUMMARY  The  standard  applies  to  interface  systems  for 

computer  system  components  interconnected  by  way  of  a  100- 
line  parallel  backplane  commonly  known  as  the  S-100  bus.  The 

total  transmission  path  among  interconnected  devices  is  less 
than  25  inches  (63.5  cm). 


CONNECT  ION  TO  CAIS  none.  Standard  696  controls  the  hardware 
i nter  face. 


REVIEW  DATE  21  September  1984 
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ABSTRACT 


The  c  h  ara  c  ter -ima  g  ing  computer  terminal/  consisting  of  a  display 
device  and  keyboard/  is  the  most  widely  used  means  of 
communicating  with  computer  systems.  Even  noui>  with  relatively 
well  developed  techniques  for  device  independence/  programs  tena 
to  be  targeted  for  either  specific  character-imaging  computer 
terminals  or  a  very  small  subset  of  charac ter- imag ing  computer 
terminals.  A  complete  i ntermed i ate- 1  eve  1  virtualization  of  a 
c har a c ter -ima g ing  computer  terminal  will  promote  program 
t r an s p or t ab i 1 i ty  /  high  level  terminal  abstractions/  and  maximum 
flexibility  for  a  tool  writer.  If  this  intermediate-level 
v i rtual i z ati on  conforms  to  an  existing  standard  for  the  device 
character  istics  of  the  character-imaging  computer  terminal  c  AIMS  I 
X 3  64-1979)/  there  will  be  many  advantageous  side-effects  Th? 
virtualization  will  closely  match  the  functional  characteristics 
of  the  conforming  character  imaging  computer  terminals-  the 
virtualization  will  be  more  widely  accepted/  device  independence 
can  be  promoted,  and  upwa r d-c omp a t i b i 1 l ty  of  the  v i r tua  1  l :  a 1 1  or 
will  more  closely  follow  the  u p war d— c ompa t i b 1 1  1 1 y  or  the 
s  candard 
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1  Introduction 


This  document  presents  a  specification  and  rationale  for  an 
i nter med i ate- 1  eve  1  virtualization  of  c h arac ter- imag ing  computer 
terminals.  The  information  presented  covers  six  areas  an 
introduction  to  virtual  terminals  and  device  independence,  a 
multi-class  and  multi-level  approach  to  c har ac t e r i z i ng  existing 
computer  terminals;  a  four  layer  approach  to  terminal 
virtualization;  an  introduction  to  computer  terminal 
s  tana  ard  i  z  at  i  on  efforts;  and.  conclusions. 

A  virtual  terminal  is  "a  conceptual  terminal  which  is  defin-c  as 
a  standard  for  the  purpose  of  uniform  handling  of  a  variety  of 
actual  terminals"  CDAV793.  There  are  four  goals  that  sfiOuia  pe 
addressed  in  specifying  a  virtual  terminal  A  virtual  terminal 
should:  enhance  trans portabi 1  l  ty  of  programs  that  perform 

c  cmputer/ terminal  interaction;  provide  a  common  interface  for 
terminals  produced  by  a  wide  variety  of  manufacturers,  provide 
the  tool  developer  with  an  extensive  set  of  interactive  terminal 
control  functions;  and.  provide  the  virtualization  at  a  level 
that  supports  many  different  models  of  c omp u t er / t erm  i  n; i 
inter  acti  on. 


-  1  - 
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2  An  Intermediate  Level  Virtual  Terminal  Rationale 

The  virtual  terminal  can  be  defined  at  many  levels.  The  loin 
level  virtual  terminal  presents  the  tool  writer  with  a  model  of 
the  computer  terminal  that  supports  direct  manipulation  of  the 
terminal  hardware.  An  intermediate  level  virtual  terminal 
presents  the  tool  writer  with  a  model  of  the  computer  terminal 
that  closely  resembles  the  functional  characteristics  of  the 
terminal  hardware  The  highest  level  virtual  terminal  presents 
the  tool  writer  with  a  model  which  hides  the  functional 
characteristics  of  the  terminal  hardware 

A  virtual  terminal  at  the  low  level  provides  a  tool  writer  with 
maximum  flexibility  An  example  of  a  low  level  model  is  tne 
actual  device  interface  presented  to  the  tool  writer  from  a 
modern  operating  system  But  the  tool  writer  must  completely 
define  his  own  model  of  the  computer  terminal  with  each  tool  be 
writes  With  many  tool  wr iters  talas,  even  with  the  same  tool 
writer),  many  different  terminal  models  at  all  levels  of 
sophistication  could  then  exist.  This  would  promote  confusion 
Also,  the  flexibility  gained  at  this  level  allows  a  tool  writer 
to  i n d 1 s c r imi nant 1 y  use  facilities  of  one  terminal  that  may  net 
be  available  at  any  other  terminal,  even  with  simulation  This 
promotes  undesirable  device  dependence 


Page  3-419 


A  Virtual  Terminal  Specification  and  Rationale 

A  vii  tual  terminal  at  a  high  level  imposes  a  model  on  the  tool 
writer  An  example  of  a  high  level  model  is  the  concept  of 
equating  a  physical  terminal  to  a  text  file  and  using  text  file 
I/O  techniques  to  address  and  control  it.  This  model  tends  to 
hide  the  functional  characteristics  of  the  terminal  hardware  It 
promotes  device  independence  and  generally  provides  a  clean 
interface  with  the  terminal.  The  disadvantag es  of  this  level  are 
twofold  First>  the  tool  writer  may  wish  to  define  a  different 
model  of  the  computer  terminal  than  the  one  with  which  he  is 
presented.  He  would  have  to  define  the  new  model  in  terms  of  the 
original  model  that  itself  does  not  model  the  terminal  hardware 
Even  modeling  the  terminal  hardware  is  awkward.  The  tool  writer 
must  model  the  terminal  hardware  in  terms  of  the  existing  model 
that  hides  the  hardware.  Second-  the  ability  to  integrate  new 
terminal  hardware  into  the  existing  model  promises  to  be  veTy 
difficult. 

An  intermediate  levei  virtual  terminal  that  presents  the  tool 
writer  with  a  miodel  of  a  functionally  advanced  hardware 
definition  of  a  character-imaging  computer  terminal  permits  great 
flexibility  for  the  tool  writer  while  maintaining  a  level  of 
abstraction  An  example  of  an  intermediate  level  model  is  er. 
abstract  representation  of  the  functionality  found  in  most 
advanced  computer  terminals.  Since  the  virtual  terminal  models 
the  advanced  computer  terminal)  those  functions  supported  in  the 
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terminal  hardware  are  available  to  the  tool  writer  directly. 
Those  functions  not  directly  supported  in  the  terminal  iaroware 
can  be  simulated  within  the  virtual  terminal.  This  will  be 
discussed  later.  The  tool  writer  could  then  define  his  own  high- 
level  abstract  model  in  terms  of  this  intermediate-level  abstract 
model.  Through  a  proper  choice  of  the  inter mediate-level 
interface)  the  virtual  terminal  couid  model  most  of  the  terminals 
on  the  market  today  and  provide  upwa r d-c omp a t i b i 1 i t y  for  new 
hardware 


-  4  - 


Page  3-421 


A  Virtual  Terminal  Specification  and  Rationale 


3  Device  Independence 

3  1  Device  Independence  techniques.  Device  independence  is 
typically  achieved  by  assuming  some  standard  device  and  mapping 
existing  devices  into  the  standard.  There  are  essentially  three 
choices  for  the  standard  device:  the  simple  device;  the  complex 
oevice.  and  some  device  of  intermediate  complexity. 

The  simple  device  is  typically  the  easiest  to  implement  and 
manipulate  An  example  of  a  simple  device  is  a  printing 
terminal  The  major  problem  with  the  simple  approach  is  that  it 
dees  not  address  the  advanced  features  of  the  computer  terminals 
on  the  market.  A  user  who  purchases  a  computer  terminal  with 
advanced  features  will  reasonably  expect  to  be  able  to  use  some 
of  them. 

The  intermediate  complexity  device  has  essentially  the  same 
advantages  and  problems.  An  example  of  an  intermediate 
complexity  device  is  a  2-d imensi onal  display  device  with  direct 
cursor  a d dr e s si b  i  1 1 1 y  It  is  reasonably  easy  to  implement  ana 
manipulate  but  does  not  provide  the  support  for  the  advanced 
computer  terminals  on  the  market  This  level  would  be  the  miost 
frustrating  to  work  with.  A  tool  writer  would  begin  to  get  a 
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flavor  of  what  he  wanted  to  do  but  may  not  be  able  to  completely 
"get  at"  the  features  he  needs 

The  complex  device  has  an  interesting  set  of  advantages  and 
d i sad vant ages .  An  example  of  a  complex  device  would  be  an  ANSI 
compatible  computer  terminal  with  advanced  functions  such  as 
graphic  rendition  (highlighting,  blinking,  etc),  insert  line, 
delete  character,  etc.  The  complex  device  would  have  a  robust 
set  of  operations  available.  A  tool  writer  would  be  presentee 
with  a  very  complete  set  of  procedures  and  functions  from  which 
to  choose  to  accomplish  his  goal.  He  would  be  able  to  take 
advantage  of  many  features  available  on  the  most  complex  comiputer 
terminals  on  the  market.  The  complex  device  would  be  the  most 
difficult  to  implement  and  manip ulat e.  If  a  user  did  not  have  a 
computer  terminal  that  supported  the  operations  defined  in  tr,e 
complex  device,  it  would  be  left  to  the  device  driver  or  some 
simulation  level  of  software  to  sustain  the  myth  that  he  did  nave 
such  a  device. 

Although  the  complex  device  requires  some  level  of  simulation  to 
achieve  the  advanced  features  on  simple  terminals,  it  appears  to 
be  the  most  advantageous  approach.  Computer  terminals  are  now 
reaching  the  market  that  incorporate  many  advanced  features  The 
terminal  manufacturers  are  beginning  to  incorporate  the  concepts 
and  f unc t i ona 1 1 ty  defined  in  the  ANSI  standard  X3.  64.  To  conform 
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to  the  ANSI  standard  has  very  worthwhile  effects.  It  helps 
formulate  the  model  as  a  complex  device  that  promotes  oevice 
independence  in  charactei — imaging  computer  terminals.  The 
conforming  computer  terminals  appear  much  the  same  from  one 
manufacturer  to  another  in  terms  of  their  operations 

3.2  Device  Independence  in  Existing  Applications.  Four  concepts 
concerning  device  independence  that  are  applicable  to  character- 
imaging  computer  terminals  are  presented  in  this  section.  Tne 
concept  of  layered  communication  is  derived  from  the  field  of 
computer  networking  LDAV793.  The  concept  of  the  terminal 
capabilities  database  was  developed  by  Bell  Labs  for  the  UNIX 
operating  system  CUNI X  is  a  registered  trademark  of  Bell  Labsj  to 
promote  computer  terminal  device  independence  CJ0V81D.  Two 
concepts  are  derived  from  the  field  of  computer  graphics  The 
concept  of  levels  and  classes  of  support  [C0R793.  and  the  concept 
of  "bundling"  attributes  CGKS823. 

A  two  level  approach  to  device  independence  has  evolved  out  of 
necessity  in  the  field  of  computer  networking.  A  compute- 
terminal  communicates  with  a  local  controlling  intelligence  to 
perform,  h  uman /comp  uter  interactions.  The  local  intelligence  then 
communicates  with  the  remote  host  in  a  standard  way  to  transfer 
the  data  the  terminal  user  produced  or  requested.  In  this 
manner,  regardless  of  the  actual  terminal  connected  to  the  local 
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intel 1 iaence.  the  remote  host  sees  all  terminals  essentially  the 
same  way.  It  is  up  to  the  local  intelligence  to  make  use  of  the 
features  available  on  the  computer  terminal.  CDAV793 

Bell  Labs'  UNIX  operating  system  provides  the  tool  writer  with  a 
database  containing  information  on  many  terminals  currently  on 
the  market.  Using  the  database*  a  tool  can  be  made  device 
independent  to  a  certain  degree.  Of  course.  if  a  tool  writer 
makes  use  of  a  facility  of  his  terminal  that  is  not  supported  or. 
another  terminal,  it  is  up  to  the  tool  writer's  software  to 
simulate  that  facility  or  not  proceed  with  the  execution  of  the 
program.  CJOYS13 

The  field  of  computer  graphics  probably  has  the  most  difficult 
task  in  trying  to  achieve  device  independence.  There  are  many 
different  kinds  of  graphic  devices  for  both  input  and  output 
There  are  two  widely  accepted  proposed  standards  for  computer 
graphic  devices:  the  ACM  CORE  standard  CCORTyj,  ana  the  ISO 

Graphical  Kernel  System  (GKS)  CGKSS23  This  terminal 

virtualization  does  not  encompass  computer  graphics  devices,  sucn 
material  is  available  in  the  references.  The  two  important 

derives  concepts  that  are  applied  to  this  virtualization  are 
the  concept  of  levels  and  classes  of  support  from  the  CORE.  anc 

the  concept  of  "bundling"  attributes  from  the  GKS. 
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The  GKS  standard  has  defined  a  method  that  combines  graphic 
attributes  such  as  color,  line  width,  dashed  representation,  etc 
These  attribute  combinations  are  called  bundles.  For  example,  a 
program  which  draws  a  line  on  the  display  could  specify  a  bundle 
number  of  1.  This  line  drawn  on  one  display  device  would  have  a 
particular  r epr e sent  a t i on  (such  as  dotted  and  red)  On  another 
display  device  the  line  would  perhaps  have  a  different 

r epr e s en t at i o n  (such  as  solid,  thin,  and  black).  Regardless  of 

the  eventual  repr esentat i on  the  same  program  would  execute  on 
either  graphics  display  device.  Since  the  program  only  specifies 
the  bundle  numbers  and  not  the  actual  r e pres enta 1 1  on ,  it  is  left 
to  something  other  than  the  program  to  determine  the  actual 
representation  the  user  would  see  at  his  graphic  display  device 

The  CORE  system  has  a  complex  set  of  levels  for  input,  output, 
and  dimension.  In  order  for  a  given  device  to  provide  support 
fcr  a  given  set  of  levels  of  input,  output-  ard  dimension,  the 
device  must  implement  all  of  the  features  defined  in  that 
combination  of  levels  using  any  of  the  following:  direct 

hardware  support,  hardware  simulation  support;  or  software 
simulation  support  It  must  also  implement  no  features  found  at 
higher  levels  (even  if  the  hardware  itself  supports  it  directly) 
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4  The  Virtual  Terminal  Claeses  and  Levels 

To  apply  the  concepts  presented  above,  the  terminals  are  divided 
into  different  classes  based  on  their  operations  and 
characteristics.  A  class  identifies  a  set  of  operations  and 
characteristics  that  may  or  may  not  intersect  another  classes' 
set  of  operations.  Each  class  is  subdivided  into  levels  of 
support  Increasing  levels  within  classes  identify  additional 
functionality  of  the  terminals  in  that  class.  A  level  that  is 
said  to  be  above  another  level  within  the  same  class  is  a 
superset  of  the  lower  level. 

The  number  of  classes  should  be  small  to  incorporate  as  many 
different  terminals  as  possible  into  each  class  This  increases 
the  amount  of  simulated  f unc t i one  1 i iy  for  those  terminals  that  do 
net  support  every  function  in  its  class  and  increases 
transportabi 1 i ty 


A  terminal  that  appears  in  a  particular  class  and  level  must 
support  all  of  the  functionality  (and  on  1 u  the  functionality! 
defined  in  that  class. 
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There  are  three  obvious  c la s s i f i c at i ons :  the  scroll  mode 
terminal-  the  page  mode  terminal,  and  the  form  mode  terminal. 
These  are  numbered  0.  1.  and  2. 

The  scroll  mode  terminal  encompasses  those  terminals  that  operate 
like  hardcopy  terminals.  That  is.  when  a  carriage  return  (or  any 
terminator)  is  typed  the  terminal  scrolls  one  line  upward  The 
functionality  of  this  terminal  class  is  severely  limited  and 
therefore,,  is  the  simplest  of  the  terminal  classes. 

The  page  mode  terminal  encompasses  those  terminals  that  have  a 
two-dimensional  display  screen  that  can  be  directly  addressee  and 
may  or  may  not  have  any  local  intelligence  (i.e  VT10G.  Concept- 
100..  Visual-50'.  This  class  of  terminal  encompasses  75  percent 
or  the  terminals  on  the  market  today. 

The  form  mode  terminal  encompasses  those  terminals  that  have  form 
fill-in  capabilities  <i.  e.  IBM  3273).  That  is,  the  application 
program  presents  the  user  with  a  f orm  to  fill  m  on  his  oisplay 
screen  The  user  fills  in  the  form  by  interacting  with  the  local 
intelligence  and  transmits  the  data  to  the  host  through  some 
special  keystroke(s)  (i.e  ENTER  key). 

Three  levels  within  each  class  are  defined —  A,  B.  and  C.  Level 
A  is  composed  of  those  functions  within  the  class  that  are  well 
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defined  and  required  for  a  computer  terminal  to  reside  in  that 
class  Level  D  is  composed  of  those  functions  within  the  class 
that  are  well  defined  and  not  required  for  a  computer  terminal  to 
reside  in  that  class  (advanced  functions).  Level  C  is  composed 
of  functions  that  are  not  well  defined  and  not  required  for  a 
computer  terminal  to  reside  in  that  class.  Level  C  is  meant  for 
special  functions  that  are  standardized  within  a  particular 
installation  or  organization. 

If  a  computer  terminal  is  in  a  particular  class  and  level  it  mus  t 
support  every  function  defined  in  that  class  and  level  For 
those  terminals  that  do  not  directly  support  all  of  the  functions 
defined,  there  must  be  some  hardware  or  software  simulation  of 
those  unsupported  functions.  If  a  computer  terminal  cannot  be 
made  to  support  all  of  the  functions  in  a  class  then  that 
terminal  cannot  be  a  member  of  that  class  and/or  level. 


I 

I 

I 

I 
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5  The  Virtual  Terminal  Lauered  Structure 

Figure  1  presents  a  four  layer  approach  to  the  terminal 
virtualization.  The  four  layers  are  the  user  layer,  fcne 

simulation  lager,  the  tr an s 1  a t or / dr i v er  layer,  and  the  physical 
terminal. 


Pr  o  c  ed  ur  e/  f  unc  t  i  on 
c  a  i  1  s 


User  Layer 


#  > 

»  i 


Simulation  Layer 


!  generic  character  codes 


Terminal 
Capabil ities 
File  - 


Translator/Driver 
!  specific  character  codes 

t 

i 

!  Physical 
!  Terminal 


Fiacre  1  A  Four  Layer  Approach  to  Terminal  Virtue iiza tier 
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The  user  layer  contains  the  interface  that  the  tool  writer  sees 
This  includes  all  the  functions,  procedures,  abstract  types.  and 
exceptions.  At  this  level  of  the  model  the  functionality  of  the 

complex  computer  termini  is  visible 

The  simulation  layer  supplies  the  software  simulation  to  create 
those  functions  that  the  physical  terminal  does  not  support  out 
of  those  functions  that  the  physical  terminal  does  support.  The 
simulation  layer  is  written  in  a  high  level  language  (such  as  ADA 
or  RASCAL)  to  support  changes  and  additions  as  required. 

The  translator/dnver  layer  provides  the  mapping  from  device 
independent  generic  character  codes  into  device  specific 
character  codes  This  layer  incorporates  a  variation  of  the  UNIX 
terminal  capabilities  database  which  is  used  to  define  the 
mapping 

The  physical  terminal  layer  contains  the  actual  physical 
terminal.  It  should  be  noted  that  only  the  t rans  lator/dT iver 
layer  has  any  knowledge  of  the  exact  type  of  terminai  that 
exists.  The  simulation  layer  only  knows  that  specific  functions 
are  not  available  ana  must  be  simulated  using  otner  generic 
functions  The  user  layer  only  knows  that  the  terminal  is  of  a 

particular  class  and  level 
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The  generic  character  codes  that  are  produced  out  of  the 

simulation  layer  conform  to  ANSI  standard  X3.  64  CANS79J  As 

computer  terminal  manufacturers  begin  to  conform  to  the  standard, 
the  tr ans  lator/dr iver  and  the  simulation  layer  will  have  less  and 
less  to  do.  And,  since  the  ANSI  standard  has  upwaro 

compatibility  built  into  it,  the  entire  four  layer  approach  has 

the  same  degree  of  upward  compatibility. 
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6  Terminal  Stand ard 1 z  at i on  Efforts 

There  are  two  important  terminal  s tan dar d i za t i on  efforts  of 
interest.  the  draft  standard  ISO/DIS  6429.  2-1982  C  IS0823;  and- 
the  accepted  standard  ANSI  X3.  64-1979  [ANS793.  The  ISO  standard 
was  first  proposed  as  a  draft  in  1975.  It  was  developed  as  a 
synthesis  of  ANSI  X3.  64  and  ECMA-4S  “Additional  Controls  for 
Ch  ar  a  c  ter -Ima  g  ing  I/O  Devices.  ’’  The  ISO  standard  is  a  superset 
of  the  ANSI  standard  including  additional  standar d i z a t i on  in  the 
areas  of  graphic  rendition.,  modes,  typographic  size  selection, 
and  modal  interactions.  Related  standards  include  CANS733 
C ANS7 4 j  CANS77  3. 
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7  ANSI  X?.  64 


It  is  natural  to  use  the  functionality  defined  in  the  accepted 
standard  as  the  complex  model  of  a  charactei — imaging  computer 
terminal.  Acceptance  is  guaranteed  by  those  that  accept  the 
standard  and  wish  an  i nte rmed  i at e -1 ev e 1  vir tua 1 i zat l on  of 
computer  terminals. 

ANSI  X3  64  "defines  a  set  of  encoded  control  functions  to 
facilitate  data  interchange  with  two-dimensional  character- 
i  mao  i  no  input-output  devices’*  CANS79D  These  control  functions 
may  be  used  in  either  a  7-bit  or  8-bit  environment  following  the 
cede  structure  defined  in  CANS 74 3.  The  purpose  of  X3  64  is  to 
provide  a  set  of  control  functions  to  accomodate  the  foreseeable 
needs  in  a  variety  of  information  i nter c dan g e  applications, 
interactive  terminals  of  the  cathode  ray  tube  type.  interactive 
terminals  of  the  printer  type,  line  printers,  microfilm  printers, 
software  usage.  form  filling.  c omp os l t i on  imaging.  word 
processing,  input-output  devices  with  auxiliary  devices.  ar.c 
buffered  and  non-buffered  devices.  In  the  creation  of  a  virtual 
terminal  we  are  interested  in  only  the  interactive  terminals  ana 
form  filling  terminals.  Perhaps  this  is  too  limiting,  however, 
it  does  produce  a  nice  symmetry  and  limits  the  scope  a  great 
deal  And.  since  the  virtual  terminal  does  conform  completely 

-  17  - 


Page  3-434 


A  Virtual  Terminal  Specification  and  Rationale 


vi-ith  the  standard,  inclusion  of  other  control  functions  is  easily 
a  c  comp  1 i s  h  ed . 
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6  The  Supported  Functions 

This  section  presents  the  functions  that  the  tool  writer  can  use 
and  that  form  the  intermediate-level  computer  terminal  model. 
Table  1  presents  those  operations  that  are  well  defined  and 
required  for  a  terminal  to  be  classified  a  class  0  terminal. 
Table  2  presents  additional  operations  for  class  0  terminals, 
well  defined  and  not  required.  Table  3  presents  those  operations 
that  are  well  defi’ned  and  required  for  a  terminal  to  to  be 
classified  a  class  1  terminal.  This  class  supports  most  of  the 
terminals  on  the  market  today.  Table  4  presents  additional 
operations  that  are  well  defined  and  not  required,  supporting 
class  1  terminals.  Table  5  presents  well  defined  and  required 
operations  for  a  terminal  to  be  classified  a  class  2  terminal. 
The  semantics  of  each  of  these  operations  is  defined  somewhat  in 
the  ANSI  and  ISO  standards.  It  is  beyond  the  scope  of  this  paper 
to  give  a  complete  semantic  meaning  of  each  of  them 

There  are  no  additional  operations  identified  for  the  class  2 
terminal.  This  will  probably  change  as  more  data  is  gathered 
Also,  note  that  there  are  no  entries  for  level  c  in  any  class 
This  is  intentional,  as  this  level  is  reserved  for  installation 
e  x  ten  s i on  s 
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Certainly  other  classes  are  possible.  they  must  simply  be 
1  denti  fied. 


Table  1  Class  Oa  -  Scroll  Mode  Support 


rea  d_l  1  ne 
writ e_l  i ne 
up  date 
op  e  n 
close 
set 
reset 

k  eyb oard_act i on_mode 

cor.trol_representation_mode 


Table  2  Class  Ob  -  Additional  Functions  for  Scroll  Terminals 


read  _c  h  ara  c  t  ei- 
mr  i  t  e_c  haracttr 
se  1  ec  t_  gr^p  t,  ic_r  end  i  t  i  on 
c  ur  s or  _h  or  i  z  on  t  a  l_a  b  so  1  u  te 
c ur  s  or _h cr  i  z  on t  a  1  _ t  a b 
cursor  tab  control 
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Table  3  Class  la  -  Page  Terminal  Support 


select _graphic_rendition  select  _editing_extent 

cur  sor_h  or  i  z  onta  l__ab  so  1  ute  edit__in_display 

cur  sor_nex  t_l  in  e  ed  i  t__i n_l  i n e 

cursor_back  mar d  p  a  ss  t  hrou  g  h_a s_i s 

cursor_doum  r  edraui__d  i  sp  1  a  y 

cur  sor_f onward 

cur sor_posi tion 

cur  s  or_up 

del ete_charocter 

del ete_l ine 

era  se_c  haracter 

eras  e_  in  _display 

eras  e_i  n_l  ine 

i  n  s  e  r  t  _  1  i  n  e 

insert_charecter 

reaii_charac  ter 

reao_line 

readstring 

read _di splay 

ur i te_c hara  c  ter 

u>t  i  te__l  ine 

ii-r  i  te..s  tring 

mi  a  t  e_d  i  sp  1  ay 

update 

open 

close 

set 

reset 

k  e  y b oard_ac  t i on_mode 
c  C'ntrol_representation_mode 
inser  tion_rep lac  ement  _mod e 
s  t  at u  s_r  e  p  or t ing_tran  s  f er _mo  d  e 
eraser  e_m  ode 
vert i cal_edi t ing_mod  e 
hen  j  onta  l_ed  iting_mode 
e  d it i ng_b  ound ary_mode 
s  end_r ec  e i ve_mod  e 
d  ynami c_updat  e_mode 
1  i  ne_f  ee  d  _nem_l  i  n  e_mo  d  e 
res  e  t_t  o_in itial_state 
get_device__characteristics 
p 1 e  ase_r ep  or t_s  tatu s 
pie  a  se_r ep  or t_c  urrent_p  osi  1 1 on 
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Table  4  Class  lb  -  Additional  Functions  for  Page  Terminal  Support 


cursor_bacl(tab 
cursor_hori zontal_tab 
cursor_tat)_control 
era  se_i n_ar  ea 
define_qualified_area 
accept_al  l_input 

accep  t_no_inp ut_and_d  o_not_transmit 
accep  t_oraph i cs 
accept  _num  erics 
accept_alpbabetics 
r  ight_justifu_in_area 
ierc_fill_in_area 

hornonta  1  _ta  b_s  t  op_a  t_s  t  ar t_o  f_ar  ea 
accept  _no_inp  ut_b  ut_s  elect  _f  or  transmission 
space_fi  1  l_in_area 
read_area 
wr  i  t  e_a r  ea 
set 
reset 

giiarded_area_tran  s  f  er  _mod  e 
mult i p le_area_transfer_mode 
t  ran s  fer_ term i nat i on_mode 
selec  ted_area_transf er_mode 
editing _b  oundary_mode 
sel ect_editing_exten t 
edit_in_qual l fied_area 
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Table  5  Class  2a  -  Form  Terminal  Support 


erase_in_display 
era  se_i n_area 
define_qualified_area 
accep  t_al l_input 

accept  _no_inp  ut_and_d  o_not_transmit 

accep  t_gr  aph i c s 

accep  t_numeri cs 

accept  _alphabetics 

right_justify_in_area 

2ero_fill _in_area 

h  c*r  i  i  onta  1  _ta  b_st  op_a  t._st  art_o  f_a rea 
accep  t_no_inp  ut_b  ut_s  elect  _f  or  transmission 
space_fil  l_in _ar e a 
>“e3(l_area 
wr l te_area 
redraw_d  isp  lay 
update 
op  e  n 
close 
set 
reset 

g  uar d ed_ar ea_tran  sf er  _mod  e 
k  etjfc o ard_ac  1 1  on_mcde 
s  tat u  s_r e  p  or t ing_tran  s  f er _mod  e 
erasur e_m  ode 

mu  It  i  p  le_area_tT'an5f:e'r_mo d  e 
trans  f er_terminat ion_mode 
seiec  ted_area_transf er_mo de 
d  ynamic_update_mode 
reset_t  o_initial_state 
get_device_cbaracteristics 
pi  ease_report_status 
p 1 ease_T epor t_c  urr ent_p osi t i on 
passthrough_as_is 
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9  Future  Directions 

Testing  out  the  model  presented  with  real  application  programmers 
and  tool  writers  is  the  direction  in  which  this  model  will 
proceed.  This  will  hopefully  answer  the  questions  concerning  the 
model:  Is  it  complete  enough?  Is  it  too  robust?  Where  are  the 

deficiencies?  It  will  then  be  necessary  to  adjust  the  operations 
within  the  classes  to  more  accurately  reflect  terminals 
c  apab i 1 1 1 i es 

In  the  long  term,  attempts  will  be  made  to  define  new  classes  to 
cover  terminals  that  are  just  beginning  to  emerge  on  the  market 
These  terminals  begin  to  approach  the  functionality  of  displays 
found  or  such  workstations  as  the  Apple  LISA.  Xerox  Star,  ana 
Smalltalk.  Also,  support  will  probably  need  to  be  provided  for 
the  most  simple  t  erm  i  na  1 -1 1  k  e  device.  An  example  is  an 
applications  in  which  a  device  that  is  not  a  computer  terminal  is 
connected  into  the  physical  terminal  layer.  This  could  be  a 
hardware  debug  device  or  a  networking  device  that  neeos  a 
completely  different  model  than  that  presented  here.  There  will 
be  a  need  to  incorporate  more  operations  defined  in  the  ANSI 
standard  as  the  terminal  manufacturers  begin  incorporating  them 
into  their  terminals  Along  the  same  lines,  c on s i der a t i o n  should 
be  given  to  incorporating  some  of  the  ISO  standard  into  tne 
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model.  Consideration  should  also  be  given  to  the  new  proposed 
teletext  and  videotex  standards. 
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1  0  C  one  I  usi  oris 

Character-imaging  computer  terminals  are  complex  devices  that 
need  to  treated  as  such.  This  paper  presents  a  virtuali zation  of 
these  types  of  devices  to  enhance  transportability  of  programs 
that  perform  computer/terminal  interaction,  to  provide  a  common 
interface  for  terminals  produced  by  a  wide  variety  of 
manufacturers,  to  provide  the  tool  developer  with  an  extensive 
set  of  inter active  terminal  control  f unctions,  and  to  provide  the 
virtualization  at  a  level  that  supports  many  different  monels  of 
computer/terminal  interaction. 
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PROTOTYPING  THE 
COMMON  APSE  INTERFACE  SET 

(CAIS) 


Tricla  Oberndorf 
Naval  Ocean  Systems  Center 
San  Diego,  California 


PURPOSE  OF  PROTOTYPING: 

The  general  purpose  of  any  prototyping 
activity  is  to  experiment  with  new  ideas.  It  is 
a  means  of  assisting  a  group  in  learning  what 
the  potential  problems  associated  with  various 
solutions  would/could  possibly  be.  An  apparent 
problem  could  have  several  potential  solutions. 
Prototyping  allows  us  to  pursue  those  poten¬ 
tial  solutions  and  also  to  further  define  what 
the  original  problem  is  in  reality.  The  purpose 
of  CAIS  prototyping  activities  will  be  to  judge 
several  features  of  the  interface  set  and  to 
gather  feedback  which  can  be  used  to  im¬ 
prove  the  CAIS. 

Prototyping  as  discussed  above  actual¬ 
ly  has  three  parts.  One  is  the  development  of 
the  actual  prototype  itself.  The  second  one  is 
the  definition  of  an  experiment  which  will  be 
designed  to  determine  the  answers  to  some 
carefully  articulated  questions  regarding  the 
CAIS.  The  third  is  the  recording  of  the  results 
of  the  experiment  in  such  a  fashion  as  to  be 
useful  to  the  technical  community  (in  this  case, 
particularly  to  the  CAIS  designers).  These  three 
together  -  implementing  a  prototype,  conduct¬ 
ing  a  planned  experiment(s)  using  it,  and  then 
reporting  the  results  in  a  useful  form  -  are 
what  is  meant  in  the  remainder  of  this  paper 
when  the  word  " prototyping "  is  used. 


SUGGESTED  EXPERIMENTS: 

Many  different  kinds  of  experiments 
should  be  planned  and  executed.  Each  should 
be  carefully  designed  and  planned  to  deter¬ 
mine  various  aspects  of  how  the  CAIS  func¬ 
tions  in  real  use.  Criteria  which  will  be  used 
to  evaluate  the  CAIS,  the  prototype  implemen¬ 
tation  and  the  experiments  conducted  using  it 
should  be  established  before  implementation 
work  begins.  Several  areas  of  experimentation 
arc  suggested  below. 

1.  CAN  THE  CAIS  BE  IMPLE¬ 
MENTED? 

This  is  the  first  question  which  must 
be  answered.  In  order  to  determine  an  answer, 
many  prototypes  on  many  different 
machines/OSs  must  be  attempted  and  their 
results  published.  It  should  be  made  clear  that 
it  is  not  a  particularly  useful  result  of  such 
an  implementation  experiment  to  simply  con¬ 
clude  "we  did  (did  not)  succeed  in  implement¬ 
ing  the  CAIS."  The  result  of  an  attempt  to 
provide  a  prototype  implementation  will  probab¬ 
ly  not  be  so  black  and  white.  The  result 
should  be  not  only  the  operational  prototype, 
but  a  report  which  explicitly  evaluates  the 
CAIS  and  the  prototype  implementation  with 
respect  to  the  ease/difficulty  encountered,  etc., 
according  to  the  evaluation  criteria  established 
before  implementation  work  began. 
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How  many  is  ’many*?  Some  people 
have  called  for  at  least  2  ’major*  implemen- 
tations.  This  undoubtedly  means  at  least  two 
implementations  of  the  complete  interface  set 
on  major  machine/OS  combinations  which  are 
in  heavy  use  in  the  probable  CA1S  user  com¬ 
munity  and  which  differ  significantly  (UNIX1 
on  IBM  and  UNIX  on  DEC  would  probably 
not  qualify  because  the  OSs  would  not  be 
sufficiently  different  to  really  prove  the  general 
implementability  of  the  CAIS).  In  some  sense, 
the  implementability  question  is  really  ’Can 
the  CAIS  be  implemented  on  a  given 
OS/machine  combination?*.  Once  this  question 
has  been  answered  positively  "enough"  times, 
the  answer  to  the  overall  question  can  be 
"yes". 

More  than  one  group  should  attempt 
implementations  on  the  same  OS,  particularly 
if  it  is  an  especially  popular  one.  This  is  al¬ 
ready  happening  with  the  CAIS,  as  several 
independent  groups  are  investigating  CAIS 
prototypes  based  on  UNIX.  The  value  of  this 
is  the  insight  gained  into  the  variety  of  ways 
in  which  CAIS  features  can  be  approached 
for  implementation  and  the  affects  which  these 
choices  have  on  how  various  features  interact 
with  one  another  in  general  and  on  the  suc¬ 
cess  of  the  implementation  effort  as  a  whole. 

Since  many  experiments  can  and  will 
be  conducted  using  only  a  partial  implemen¬ 
tation  of  the  CAIS,  one  preliminary  question 
will  have  to  be  answered:  is  the  CAIS  amenable 
to  incremental,  tailored  implementation? 

2.  CAN  THE  CAIS  BE  IMPLE¬ 
MENTED  EFFICIENTLY? 


This  is  the  second  major  question  to 
be  answered.  This  calls  for  prototypes  of  a 
slightly  different  nature  than  the  first  ques¬ 
tion  does.  These  prototypes  will  emphasize 
speed  of  execution,  not  speed  of  implementa¬ 
tion.  They  might  well  be  done  independently 
of  any  prototype  answering  question  1,  or  they 
might  be  based  on  such  a  prototype,  focus¬ 
ing  on  the  design  choices  which  were  made 
for  quickness  of  implementation  instead  of  ex¬ 
ecution  efficiency. 

Another  aspect  of  "efficiency*  is  how 
much  effort  is  required  to  produce  a  reasonable 
CAIS  implementation.  Estimates  so  far  range 
from  S500K  to  $6M  and  from  6  months  calen¬ 
dar  time  to  10  years.  One  proposed  criterion 
for  'ease  of  implementation"  is  that  it  would 
take  less  than  5  manyears  over  a  period  of 
one  calendar  year.  Of  course,  such  figures  will 
vary  with  the  purpose  and  other  parameters 
of  the  prototype  implementation  experiment, 
but  it  is  another  aspect  on  which  we  need  to 
gather  information.  Carefully  kept  records 
regarding  budgets,  calendar  time,  personnel  and 
machine  resources  required  to  implement  a 
given  prototype  should  be  a  part  of  any 
prototype  report. 

In  this  case,  too,  many  prototypes  are 
needed.  Also,  as  above,  there  is  value  both 
in  a  wide  variety  of  such  prototypes  and  in 
several  of  them  implemented  by  independent 
groups  on  the  same  machine/OS. 

3.  CAN  USEFUL  TOOLS  BE 
IMPLEMENTED  USING  THE  CAIS? 

Many  different  kinds  of  experiments 
are  needed  in  this  area.  One  aspect  is  the 
ability  of  the  CAIS  to  support  the  sorts  of 
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tools  which  are  in  common  use  today;  the 
corollary  to  this  experiment  would  determine 
which  interfaces  common  tools  require  which 
the  CA1S  does  not  currently  provide.  A  second 
aspect  is  the  ability  of  the  CAIS  to  support 
the  sorts  of  tools  which  can  be  anticipated  in 
the  future;  an  analogous  corollary  would  deter¬ 
mine  the  requirements  which  more  forward- 
looking  tools  may  place  on  the  interfaces. 
Another  aspect  is  the  ability  of  the  CAIS  to 
capture  existing  tools;  i.e.,  what  are  the  dif¬ 
ficulties  encountered  in  rehosting  existing  tools 
on  the  CAIS.  Experiments  dealing  with  such 
difficulties  should  consider  not  only  existing 
tools  written  in  Ada2,  but  also  the  problems 
which  are  presented  by  tools  written  in  other 
languages  and  by  tool  sets.  A  fourth  aspect  of 
tool  iraplcmentability  is  what  affect  the  CAIS 
features  have  on  the  design  of  tools.  One  use¬ 
ful  experiment  in  this  regard  might  be  to  take 
an  existing  set  of  tools  already  rehosted  to  the 
CAIS  and  redesign  it  to  take  the  best  ad¬ 
vantage  of  the  CAIS  interfaces  and  implemen¬ 
tation. 

4.  DOES  THE  CAIS  ACHIEVE 
ITS  TRANSPORTABILITY  OBJEC¬ 
TIVE? 

This  is  ultimately  the  experiment  that 
is  of  interest  in  demonstrating  the  original 
design  goal  of  the  CAIS.  Such  an  experiment 
would  be  conducted  by  attempting  to  move 
a  tool  or  toolset  which  has  been  successfully 
hosted  on  one  CAIS  implementation  to  another 
(different)  CAIS  implementation.  Since  transpor¬ 
tability  is  not  an  all  or  nothing  proposition, 
careful  records  should  be  kept  regarding  the 
difficulties  encountered,  the  interface  changes 
required,  the  effort  required,  etc.;  this  infor¬ 
mation  would  form  the  basis  for  estimating 
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how  much  of  the  code  was  transported  and 
how  much  had  to  be  redone  in  order  for  the 
tool  or  toolset  to  execute  properly  on  the  new 
CAIS  host.  These  experiments  should  be  con¬ 
ducted  both  with  tools/toolsets  which  have  been 
designed  to  be  portable  and  with  those  that 
have  not. 

In  this  case  as  with  the  others,  the 
more  such  experiments  that  are  conducted,  the 
more  information  about  the  appropriateness  and 
viability  of  the  CAIS  can  be  gathered. 

5.  CAN  THE  CAIS  BE  EX- 
TENDED? 

At  least  three  very  important  future 
aspects  of  the  CAIS  are  not  yet  dearly  un¬ 
derstood.  These  and  others  should  be  the  ob¬ 
ject  of  further  CAIS  prototype  experiments. 
The  emphasis  in  such  experiments  would  shift 
from  proving  the  utility  of  what  is  already 
in  the  CAIS  to  identifying  aspects  of  the 
CAIS  which  will  either  hinder  or  enable  fu¬ 
ture  extensions. 

The  first  identified  set  of  extension  ex¬ 
periments  should  deal  with  the  distributivity  of 
the  CAIS.  It  is  recognized  by  the  community 
as  a  whole  that  the  direction  of  implementa¬ 
tion  of  software  development  and  maintenance 
environments  is  towards  use  of  multiple  com¬ 
puters,  possibly  including  personal  workstations. 
Linked  together  to  provide  the  complete  set  of 
capabilities  which  are  available  to  a  user.  The 
CAIS  may  be  called  upon  to  be  distributed  in 
either  of  two  modes:  either  as  several  inde¬ 
pendent  CAIS  implementations  capable  of  com¬ 
municating  and  cooperating  with  one  another 
or  as  one  complete  CAIS  implementation  which 
spans  two  or  more  independent  processors.  Ex- 


®  Ada  is  a  registered  trademark  of  the  U.S.  Government  (Ada  Joint 
Program  Office). 


Page  3-449 


pcriments  regarding  distributivity  would  have 
at  least  two  aspects:  is  the  CA1S  distributable 
in  either  mode  (in  a  transparent  sense)  as  it 
is  now  and  can  explicit  interfaces  dealing  with 
aspects  of  distribution  in  either  mode  be  smooth¬ 
ly  integrated  with  the  existing  CA1S  interfaces. 

The  second  set  of  extension  experiments 
should  deal  with  the  database  aspects  of  the 
CAIS.  These  experiments  might  investigate  a 
number  of  aspects,  such  as: 

-  what  sorts  of  database  applications 
are  well  supported  by  the  current 
CAIS? 

-  what  level  of  database  operation 
should  be  directly  provided  by  the 
CAIS? 

-  what  kinds  of  database-related  inter¬ 

faces  are  required  to  be  incor¬ 
porated  into  the  CAIS? 

-  what  sort  of  database  model  will 
best  support  the  widest  range  of 
tool  requirements? 

The  database  portion  of  the  STONEMAN3  ap¬ 
proach  to  an  environment  is  the  least  under¬ 
stood,  least  proven  and  potentially  most 
important  part  of  the  new  approach  to  en¬ 
vironments.  It  is  a  key  issue  for  future  ver¬ 
sions  of  the  CAIS,  so  whatever  information 
can  be  derived  from  prototypes  should  be 
gathered  and  provided  to  the  CAIS  designers. 

The  third  set  of  extension  experiments 
should  deal  with  the  ability  of  the  CAIS  to 
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support  adequately  the  sophisticated  user  in¬ 
terfaces  required  by  such  devices  as  bit -mapped 
and  graphics  terminals.  It  is  acknowledged  in 
the  initial  version  of  the  CAIS  that  such  in¬ 
terfaces  are  of  future  interest.  Prototypes  which 
help  to  investigate  this  aspect  of  extension  are 
also  needed. 

6.  IS  THE  SAME  CAIS  AP¬ 
PROPRIATE  FOR  BOTH  OS  AND 
BARE  MACHINE  IMPLEMENTA¬ 
TIONS? 

This  issue  has  been  brought  up  recent¬ 
ly  in  the  KIT/KJTiA,  but  there  has  not  been 
enough  information  so  far  to  adequately  deal 
with  it.  To  some  extent,  the  prototypes  which 
will  result  from  questions  1-5  above  could 
provide  insight  into  this  issue,  but  some  ex¬ 
periments  must  be  designed  explicitly  to  ob¬ 
tain  information  in  this  regard. 

FEATURES  OF  THE  CAIS: 

Any  experiment  might  be  designed  to 
investigate  a  number  of  CAIS  features.  These 
features  include: 

-  the  level  of  the  interfaces  (too 
high,  too  low,  just  right) 

-  the  size  of  the  interface  set  (too 
large,  too  small,  minimal) 

-  the  determination  of  interfaces 
which  are  least  important 

-  the  appropriateness  of  the  underly¬ 
ing  node  model  to  the  support  of 
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the  requirements  of  software 
development  and  maintenance 

-  the  implementability  of  the  CAIS 
on  a  wide  range  of  machine/OS 
combinations  (including  bare 
machines) 

-  the  ease  (or  difficulty)  of  implemen¬ 
tation 

-  the  compatibility  of  the  CAIS  with 
various  security  models 

-  the  ability  of  the  CAIS  to  capture 
(i.e.,  be  the  target  of  a  reasonably 
straightforward  rehosting  of)  existing 
tools 

-  the  usability  (i.e.,  by  tools  and 
toolwriters)  of  the  interfaces 

-  the  performance/efficiency  achievable 

-  the  portability  of  CAIS  implementa 
tions 

-  the  determination  of  missing  and/or 
extraneous  interfaces 

-  the  applicability  of  the  interfaces 

-  the  distributivity  of  the  CAIS. 

Which  features  are  to  be  investigated  by  the 
prototyping  activities  and  how  the  results  will 
be  measured  (i.e.,  what  criteria  will  be  used 
and  how  the  evaluation  of  the  prototype  with 
respect  to  those  criteria  will  be  conducted) 
should  be  a  part  of  any  experiment  design. 


As  experiments  addressing  the  various 
features  and  issues  are  conducted,  results  will 
be  obtained  which  can  be  conveyed  to  the 
CAIS  designers  and  to  other  CAIS  users. 
However,  it  will  be  important  to  distinguish 
between  several  aspects  of  the  experiments 
and/or  the  implementation  which  might  be 
revealed  by  a  result  of  the  work.  Any  given 
result  could  be  a  comment  on: 

-  the  interface  set 

-  the  underlying  CAIS  model 

-  the  underlying  machine  or  operat¬ 
ing  system 

-  the  design  or  implementation 
choices  made  in  building  the 
prototype 

-  the  design  of  the  experiment  itself 

-  the  team  conducting  the  implementa¬ 
tion  and  experiment. 

Other  factors  might  also  be  involved.  It  will 
be  very  important  that  the  final  analyses  take 
into  account  that  any  or  all  of  these  might 
have  contributed  to  any  given  result.  For  ex¬ 
ample,  it  would  not  be  helpful  to  conclude 
that  some  outcome  indicated  an  interface 
deficiency  when  the  real  problem  might  lie 
with  some  feature  of  the  node  model  or  some 
particular  design  choice  that  was  made.  All 
final  analyses  should  attempt  to  determine  ex¬ 
actly  why  an  interface  was  found  to  be  defi¬ 
cient. 

KINDS  OF  PROTOTYPES: 


Several  different  prototype  approaches 
ASPECTS  REVEALED  BY  THE  EX-  might  be  used  in  the  experiments  which  are 
PERIMENTS:  designed  to  answer  questions  about  features  of 

the  CAIS: 
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efficiency  of  implementation 


1.  Full  or  partial  implementations  of 
the  CA1S  which  are  brought  up  as  quickly  as 
possible  in  order  to  prove  implementability,  to 
provide  a  base  for  tool  implementation  experi¬ 
ments,  etc.  Such  prototypes  would  not  em¬ 
phasize  efficiency  of  implementation  or  speed 
of  execution;  the  primary  emphasis  would  be 
on  functionality. 

2.  Full  or  partial  implementations  of 
the  CAIS  which  are  designed  to  be  as  effi¬ 
cient  as  possible  and  to  execute  as  quickly  as 
they  can  on  that  machine/OS  combination.  Such 
prototypes  would  provide  insight  into  the 
parameters  of  CAIS  efficiency,  implementability 
for  efficiency,  implementation  tailorability,  etc. 

3.  Full  or  partial  implementations  of 
tools  which  are  designed  or  converted  to  ex¬ 
ecute  using  the  CAIS  interfaces.  The  purpose 
of  such  prototypes  would  be  not  only  to  prove 
the  usability  of  the  interfaces  for  tool  im¬ 
plementation  but  also  to  provide  feedback  on 
additional  interfaces  which  might  be  usefully 
added  to  the  CAIS.  (Note  that  this  requires  1 
or  2  above.) 

4.  Full  implementations  of  tools  or  tool- 
sets  which  are  designed  to  simulate  a  full 
APSE  and  therefore  to  provide  insight  into 
the  functioning  of  the  CAIS  as  the  basis  for 
a  full  APSE. 

From  the  above,  it  is  clear  that  there 
are  several  variables  which  might  be  traded 
off  in  order  to  provide  a  prototype  implemen¬ 
tation  which  was  best  suited  to  the  planned 
experiments: 


-  speed  of  execution 

-  completeness  of  interface  set  used 

-  number  of  tools  implemented  on 
top  of  the  CAIS  implementation 

-  type  of  tool(s)  implemented  on  top 
of  it 

-  ease  of  implementation 

-  evolvability  to  a  viable  end-product. 

Each  prototype  will  be  based  on  a  unique  set 
of  design  choices  which  are  determined  by 
the  objectives  of  the  prototype,  the  experiments 
which  have  been  designed  for  the  prototype 
and  the  machine/OS  combination  on  which  the 
prototype  will  be  hosted. 

CURRENTLY  IDENTIFIED  EX  PERI- 

MENTS: 

The  following  groups  are  currently  plan¬ 
ning  experiments  with  CAIS  prototype  im¬ 
plementations.  Some  of  the  prototype 
implementations  are  underway. 
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CAIS  PROTOTYPES 


AdaPAKSS  Project 
CAIS  Prototype  Task 


A  Report 
to 

KIT  /  KITIA 


TRW 

16  January  1985 
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Prototype 
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CAIS  Prototype  Task  Team 
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(Hal  Hart) 

Frank  Belz 

Frank  Tadman  (UCI  /  TRW) 
Tony  Alden 
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Prototyping  a  Moving  Target 


TRW  Effort 


Learn 


Feedback 
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Establish/Befine  Eualuatiaa  Criteria 


Evaluate  The  CAIS  Itself 
Evaluate  CAIS  Implementations 
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Evaluating  The  CAIS  Itself 


Consistency 

Completeness 

CAIS  implementability 

APSE  Implementability 

Performance  Restrictions 

Portability  Support 

Appropriateness 

Interface  Level 
Size  of  Interface  Set 
Relative  Importance  of  Interfaces 
Node  Model 


Distributivity 


Evaluating  CAIS  Implementations 


Performance 
Overhead 
Response 
Size  Limitations 
Host  System  Visibility 
Tool  Capture 
Data  Base  Capture 
Error  Recovery 
Error  Reporting 
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Evaluating  CAIS  Implementations 

(cont.) 

Portability 

Uniformity  &  Host  Services 

Concurrency 

Security 

Compatibility  with  various  models 
Encapsulation  (  Internal  vs.  External 

Access  Control) 

Integrity 

Host  Invasiveness 
Implementation  Dependencies 
Adaptability 


Storage  Modeling  Approaches 


-  Main  Memory 

-  Disk  Partition 

-  Disk  Segmentation 

-  Flat  Filespace 

-  Hierarchical  (UNIX)  File  System 

-  Back  End  DB  Machine 
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Main  Memory 


Quick  to  Implement 
Fast  (with  adequate  working  set) 
Capacity  Limitations  are  Severe 
(unless  single-level  a  la  hultics) 
Check  Point/Restore  required 
Concurrent  Users  Very  Difficult 
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Disk  Partition 


Potentially  most  efficient 
Potentially  maximal  capacity 
Potentially  portable 
Costly  to  implement 

Rebuild  much  O.S.  Software 

-  Free  storage  management 

-  Cylinder  optimizations,  etc. 

Unix  kernel  invasive 

-  CAOS  acceptable,  PAIS  unacceptable 
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Disk  Segmentation 


Like  disk  partition,  except 

-  Less  costly  to  implement 

-  Possibly  less  Unix-kernel  invasive 


Hierarchical  Filesystem 


Potentially  high  capacity 
Not  kernel  invasive 
Not  portable 
Performance  poor 
External  security  weak 

-  Encapsalation  impossible 

-  Integrity  vulnerable 
Non-uniform  correspondence 
Cost  risk  high 
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Flat  Filespace 


Potentially  high  capacity 
Low  cost  implementation 
Abstractly  similar  to  disk  segmentation 
-  adaptable 
Not  kernel-invasive 
Portable 

Performance  poor 
External  Security  weak 
-Encapsulation  impossible 
-Integrity  vulnerable 
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Back  End  Database 


Capacity:  maximal  ..  supermaximal 
Performance:  very  poor  ..  supermaximal 
Probably  very  high  external  security 
OS  Independent 
Back  End  Database  Dependent 

-  portable  wrt.  OS,  not  DB 
Implementation  cost  uncertain 

-  high  variance 
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Pick  a  Design  Approach 


'Cached  Segmentation* 
Segmentation 

-  Common  Abstraction  of 
Disk  Segmentation  and 
Flat  Filespace 

-  Implementation  as  Flat 
Filespace 

Cached 

-  Open  nodes,  relationships 
and  attributes  cached  in 
main  memory 


-  Extension  of  file  buffering 
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CAIS/OS  Process  Structure 


How  to  use  UNIX  processes  to  achieve: 

-  CAIS  Data  Store  Access  capabilities 

-  CAIS  Access  Control 

-  Concurrency  Control 

(serialization  of  access  to  data) 

-  Integrity  assurance 

-  CAIS  processes 
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Process  Design  Options 


Data  Store  Access  capabilities 
can  be  placed  in: 

-  Application  UNIX  processes 

-  "Companion"  UNIX  processes 

-  Single  Server  UNIX  process 

-  Within  the  UNIX  kernel 
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NAME. 

SPACE. 

MANAGE! 


USTJO 


CAIS_ 

10- 

CONTROL 


CAIS- 

10- 

EXCEPTIONS 


CAIS- 
TEXT  JO 


CAIS- 

LIST- 

UTILITIES 
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Design  Extended  CAIS  Subset 


Current  Emphasis: 

-  Access  Control 

-  Concurrency  Control 
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Experiment  /  Tool  Build 


In  our  future  plans 

Based  on  PA-APSE  tool  prototyping 
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OR  AFT 


On  DoD  Standards  for 
Computing  System 
Programming  and  Run-Time 
Support  Environments 

by 

Edgar  H.  Sibley  and  Ann  E.  Reedy 


Abstract 

There  are  some  problems  that  arise  In  specifying  any  computing 
system  standards.  These  are  found  whether  we  are  talking  about 
governmental,  national  cr  International  standards.  Ultimately, 
the  problems  and  their  solutions  are  matters  of  acceptance  and 
compliance,  and  part  of  this  Is  a  matter  of  policy  and  control 
...  be  It  at  the  local  or  global  level.  This  paper  examines 
the  problens  and  solutions  and  asks  the  questions: 

t.  Are  we,  the  KITIA,  doing  anything  of  value  for  DoD? 

2.  If  we  are,  what  Is  It? 


1 .  I  ntroducrt  I  on 

The  first  question  that  should  be  asked  Is: 

What  Is  a  standard? 

Unfortunately,  there  Is  a  large  range  of  answers,  depending  on 
the  area  and  participants.  In  order  to  make  seme  progress  we 
shall  therefore  talk  about  ’’hard  standards"  and  "soft  standards" 
though  (as  will  be  seen  later)  we  have  other  terms  that  have  been 
appl led. 


2.  "Hard"  Standards 

A  "hard  standard"  Is  defined  here  as  nationally  legal  required  or 
otherwise  rigidly  enforced  standard;  typical  examples  are  the 
Meter,  Kilogram,  Pound,  Foot,  Second,  Degree  Celsius,  Ampere,  and 
Volt.  It  Is  Interesting  to  note  that  these  do  not  Include  the 
Watt  or  Horse  Power  because  they  can  be  derived  from  the  others. 

Such  hard  standards  are  enforced  (almost  worldwide)  by  legal 
process.  First  there  must  be  a  Weights  and  Measures  body  (a 
Bureau  of  Standards)  that  has  the  sole  right  of  defining  the 
means  of  deriving  and  maintaining  the  standard.  Then  there  Is  a 
body  of  people  who  legally  check  public  compliance  (possibly  a 
Bureau  of  Weights  and  Measures).  This  body  Is  responsible  first 
for  maintaining  a  set  of  "secondary  standards."  These  must  be 
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certified  to  be  exact  copies  —  within  acceptably  small  limits  — 
and  regularly  rechecked  and  recertified  against  the  standard.  The 
body  then  uses  thes  secondary  standards  to  certify  first  class 
standard  measuring  devices  (such  as  those  used  In  machine  shop 
standards  rooms)  and  also  for  giving  out  certificates  that  shew  a 
certain  scale  or  measure  does  match  the  secondary  standard  within 
reasonable  limits.  At  this  point,  secondary  standards  may  be 
produced  for  derived  units  (such  as  the  Watt,  Calorie  and  Joule), 
since  they  are  useful  for  comparing  other  devices  for  compliance. 

The  other  prime  function  of  this  body  Is  to  check  complaints,  or 
make  spot  checks,  to  ensure,  for  example,  that  the  butcher's 
scales  or  gas  station's  punp  Is  not  short-changing  the  customers. 


3.  "Soft  Standards" 

Most  of  the  other  "Standards"  In  use  today  are  soft  —  In  the 
sense  that  there  are  only  local  "rules"  that  make  the  users 
comply  with  them.  Indeed  there  Is  a  term  that  has  been  adopted 
for  many  of  these:  "Industry  voluntary  standards."  Many  of  them 
only  exist  because  It  Is  convenient  to  the  participants;  examples 
are  nut  and  bolt  sizes,  photo  film  speeds  and  sizes,  and  pipe 
connections.  The  latter  started  In  the  USA  when  a  major  fire  In 
Baltimore  destroyed  about  a  square  mile  of  city  though  there  were 
punpers  from  as  far  North  as  New  England  (with  most  standing  Idle 
due  to  lack  of  abll Ity  to  connect  to  the  hydrantsl).  In  wartime 
(e.g. ,  the  Korean  War)  there  have  been  container  standards,  but 
these  mostly  lapsed  due  to  lack  of  Incentive  (suppl les‘  I ncreased 
and  the  Government  relaxed  Its  regulations). 

The  lack  of  Governmental  or  other  enforcement  mechanisms  Is 
generally  the  problem.  For  many  good  and  bad  reasons,  variations 
arise  locally.  Some  of  these  reasons  are: 

1.  Academics  feel  that  restriction  to  a  standard  will  slew  or 
stifle  research  In  the  area.  The  rally  long  cry  Is:  "It's  too 
soon  to  standardise." 

QPlease  note  that  if  we  wait  until  a  component  Is  not  moving 
or  changing  to  standardise  It,  It  has  probably  become 
useless  or  outmoded.  An  Interim  standard  Is  reasonable  — 
see  how  the  photo  film  standards  have  evolved} 

2.  Industry  often  feels  that  their  competitive  advantage  with 
a  current  product  Is  lost  by  Imposition  of  a  new  standard 
(that  overlaps  their  product). 

CThts  has  undoubtedly  helped  to  hold  up  many  good  Ideas  In 
the  past.} 

3.  Industry  "adopts"  the  standard,  but  there  are  too  many 
loopholes  that  allow  the  Impl  enentatl  on  to  be  sloppy  or 
diverging  from  standard  In  places.  The  law  Is  not  enforced 
generally  by  the  Government,  and  thus  these  "soft  standard" 
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requirements  may  be  disregarded  with  the  only  redress  a  civil 
suit  (with  costs  that  deter  all  but  the  wealthiest 
organizations) . 

4.  A  Lalssez  Falre  attitude  on  the  part  of  the  enforcers.  In 
this  case,  the  rules  may  say:  "Use  a  Standard"  but  monitoring 
for  compliance  Is  not  rewarding  or  Is  too  time  consuming  or 
expensive,  etc.  Unfortunately,  also,  the  enforcing  agent  Is 
often  not  fully  conversant  with  the  standard  requirements  and 
willing  to  allow  divergence.  The  powerful  player  (a  high 
corporate  executive  or  Governmental  Secretarial  Staff  member) 
believes  there  Is  a  valid  reason  for  allowing  divergence. 

Thus  the  soft  standard  can  be  seen  as  lacking  the  two  parts 
needed  In  the  hard  standards  case: 

t.  A  body  that  truly  certifies  the  standard  and  knows  how  to 
ensure  that  any  "secondary  standard"  Is  In  compliance  within 
a  specified  tolerance. 

CThls  testing  must  be  tight  enough  to  be  meaningful  —  e.g., 
a  meter  rule  that  Is  within  20 %  of  standard  Is  not  very 
useful,  yet  there  are  many  so-called  "Impl ementer  defined" 
options  In  so-called  standard  computer  language  specifications.]] 

2.  Another  body  that  has  legal  and/or  other  control  methods 
(such  as  sanctions)  against  non-compilers. 

CThls  body  must  have  almost  absolute  power  —  and  the 
realization  of  this  by  Its  detractors  Is  normally  a  precursor 
to  Its  death  knoll] 

In  between,  there  are  a  large  number  of  options  that  run  the 
gamut  frcm  hard  controls  to  none.  The  DoD  probably  Is  towards  the 
soft-end  In  computer  software  production  and  run-time  systems: 
there  are  few  standards,  they  are  subverted  easily  (or  so  It 
seems  to  the  external  observer.  Judging  by  the  large  number  of 
variations  frcm  standard  allowed),  and  there  Is  certainly  no 
tightness  In  the  testing  for  standards,  though  there  are 
attempts  to  do  so  by  fES  and  GSA,  and  through  them  by  some 
service  units. 


4.  Standards  for  Programming  and  Run-Time  Support  Environments 

Before  embarking  on  the  questions  of  pol Icy  and  economics.  It  Is 
valuable  to  ask  what  are  the  real  Issues  to  be  addressed  when 
looking  at  standards  for  computing  systems  with  special  emphasis 
on  programming  and  run-time  support  environments.  There  appear 
to  be  a  few  Issues  that  have  been  discussed  at  length  In  KIT/IA 
meetings  and  are  as  yet  only  partially  resolved.  These  Issues 
seem,  primarily,  to  devolve  on  a  need  for  long  time  naming 
continuity  and.  In  general,  software  configuration  management. 
These  Issues  will  be  used  as  examples  for  purposes  of  the 
fol  lowing  discussion. 
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The  first  Issue  Is  that  of  providing  "Unique  Names"  across 
geographic  and  time  boundaries.  The  term  "unique  name"  (UN)  has 
been  used  to  define  an  Immutable  name  for  an  object;  e.g. ,  a 
compiler  should  be  uniquely  Identified  by  a  UN,  which  neither 
changes  nor  Is  "recycled."  Thus  a  UN  Is  given  to  any  Important 
object  and  remains  Its  name  frcm  then  on,  and  If  the  object  is 
deleted/ removed,  the  UN  will  still  Identify  the  object,  but  an 
attempt  to  retrieve  It  will  result  In  a  statement  that  It  Is  no 
I  onger  aval  I  abl  e. 

There  are  two  possible  problems: 

t.  Is  any  sort  of  change  allowed  to  an  object  without  Its  UN 
changt  ng? 

CNormally,  the  contents  of  the  object  are  allowed  to  be 
altered,  but  this  could  mean  that  it  is  no  longer  even 
similar  to  Its  previous  "parent"  object.  Certainly,  It  seems 
reasonable  to  allow  the  object  to  be  a  program  named  "X"  and 
to  allow  It  to  be  debugged  without  changing  Its  name  for  each 
error  detected.  This  would  suggest  the  unique  name  was  really 
a  run-time  UN,  which  could  be  said  to  remain  constant  during 
programming  and  debugging.  However,  If  the  UN  were  for  a  data 
object,  the  effect  of  a  change  In  any  one  of  Its  values  would 
be  a  new  "version"  of  the  object,  and  this  oould  be  Important 
enough  to  be  considered  a  new  "object"  though  the  normal  way 
of  dealing  with  this  Is  to  consider  the  data  object  to  be 
"time  and  date  stamped"  with  an  audit  trail  to  'allow  the 
previous  object  to  be  reconstructed  (roll  out)  If  needed. 3 

2.  How  are  UN  related  for  the  same  (but  changed)  object? 

CAs  suggested  above,  there  Is  a  method  normally  In  use  for 
previous  data  object  reconstruction  —  the  roll  out  from  an 
audit  trail,  however,  the  data  In  a  traditional  database  must 
not  be  called  by  physical  location,  but  by  "name  pointers"  or 
indexes  or  "logical"  keys  —  these  might  be  considered  the  UN 
for  data.  On  the  other  hand,  the  only  "audit  trail"  for 
prograns  Is  normally  provided  by  the  configuration 
management  system  (CMS).  In  fact,  the  idea  of  version  in  a 
CMS  Is  another  way  of  looking  at  the  unique  name;  l.e. ,  the 
UN  Is  equivalent  to  a  user  name  concatenated  with  the  version 
number  (or  equlval ent) .3 

What  has  been  suggested  above  about  a  UN  for  both  progran  and 
data  could  also  hold  for  control  structures. 
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5.  Centralization  and  Decentralization  Issues 

The  really  tough  problems  of  unique  names  of  any  of  the 
types  of  objects  occurs  when  they  are  (In  some  way  or  other) 
decentralized.  The  traditional  hard  standards  are  normally  kept 
In  one  place,  though  It  Is  not  unreasonable  to  distribute  them 
geographically.  The  controls  are  then  distributed  by  using 
secondary  (and  less  accurate)  standards  at  the  certification  and 
complaint  checking  offices.  It  Is  therefore  Important  to  realize 
that: 

There  Is  only  one  true  "standard1’  for  any  object. 

Now  consider  the  following  scenario: 

SCENARIO  Part  1: 

A  compiler  In  Syracuse,  with  the  UN  of  Ada-56,  Is  to  be  used 
by  DoD  contractor  ABC.  For  al  I  sorts  of  reasons,  the 
contractor  now  makes  a  copy  of  It. 

First  QUESTION  Set: 

1.  Should  the  contractor  be  allowed  to  make  the  copy  or  Just 
to  use  the  compiler  remotely? 

2.  If  OK  to  copy. 

Is  the  UN  the  same?  and 

Is  there  a  central  authority  that  knows  this/or 
Is  there  a  note  with  the  Ada-56  that  says  It  has  been 
copied  by  ABC? 

3.  If  not  OK  to  copy. 

Does  the  compiler  CMS(conf Iguratlon  management  system) 
keep  track  of  all  programs  compiled  by  It? 

SCENARIO  Part  2: 

The  ABC  contractor  now  needs  to  alter  the  compiler. 

Second  QUESTION  Set: 

4.  Is  ABC  allowed  to  do  so? 

5.  If  yes. 

Is  the  UN  changed? 

If  It  Is,  who  controls  this,  and  how? 

If  not,  we  now  have  two  copies  with  the  same  UN 
but  different! 

6.  If  no, 

What  Is  the  mechanism  for  stopping  It? 

How  can  the  ABC  contractor  get  the  change  made? 

How  are  other  users  who  compiled  programs  Informed  of 
the  change?  (see  Question  3) 

SCENARIO  Part  3: 

The  Syracuse  group  now  need  to  alter  the  compiler  for  their 
own  reasons;  l.e.,  Independently  of  the  part  2  scenario. 
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Third  QUESTION  Set: 

7.  Under  what  conditions  will  the  UN  change? 

SCENARIO  Part  4  on: 

Repeat  the  whole  of  the  above  for  a  database.  Only  the 
outl Ine  Is  given: 

A  database  In  Syracuse,  with  the  UN  of  Per-67,  Is  to  be  used 
by  DoD  contractor  ABC.  The  contractor  now  makes  a  copy  of  It. 
The  ABC  contractor  now  needs  to  alter  the  data.  The  Syracuse 
group  now  need  to  alter  the  database  for  their  own  reasons; 
I.e. ,  Independently. 


Fourth  QUESTION  Set: 

8.  Should  the  contractor  be  allowed  to  make  the  copy  or  Just 

to  use  the  data  remotely? 

9.  If  OK  to  copy. 

Is  the  UN  the  same?  and 

Is  there  a  central  authority  that  knows  th I  s/or 
Is  there  a  note  with  the  Per-67  that  says  It  has  been 
copied  by  ABC? 

10.  If  not  OK  to  copy. 

Does  the  system  keep  track  of  all  users  and  their 
authorization  plus  any  triggers  that  are  to  Inform 
them  of  any  Important  changes? 

11.  Is  ABC  allowed  to  alter  data? 

Is  It  at  the  copy  or  at  the  original  (depending  on 
Question  8)? 

12.  If  yes. 

Is  the  UN  changed/  which  one? 

If  It  Is,  who  controls  this,  and  how? 

If  not.  Is  there  to  be  an  automatic  update  to  the 
original  database? 

13.  If  no. 

What  Is  the  mechanism  for  stopping  It? 

How  can  the  ABC  contractor  get  the  change  made? 

How  are  other  users  Informed  of  the  change?  (see 
Question  10) 

14.  Under  what  conditions  will  the  UN  change  when  the 

Syracuse  group  change  data? 

Obviously,  the  answer  to  much  of  the  above  question  set  Is  a 
matter  of  pol Icy  and  method  of  control.  The  answers  must  reflect 
our  beliefs  In  the  Intent  of  the  organization  (here  DoD)  and  the 
consent  of  the  participants  to  comply  with  the  "laws.” 
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The  traditional  structure  of  three  level  management  In  providing 
policy  (goals)  and  control  (operatloonal )  is  usually  as  given  by 
the  diagram: 


Pol  Icy 
| 

Top  Management 

* 

Resource  Allocation 

1 

Middle  Management 

1 

Organlzatl onal  Controls 

Lower  Management 

The  use  of  the  concept  of  distribution  of  authority  (usually 
termed  "delegation  of  authority")  gives  rise  to  one  possible 
sol ut Ion: 


Central  Control 

I 

I 

Regional  Control 

I 

I 

Local  Control 


more  levels  (as 

needed) 

This  could  allow  a  "DIctlonary/Conf Iguratlon  Management"  system 
sol  utlon  as  fol  1  cws: 

Central  Cont 

1 

Central  Dlcty 

1 

Central  Progs 

1 

1 

Regional  Cont 

1 

1 

Regional  Dlcty 

1 

1 

Regional  Progs 

1 

1 

Local  Cont 

1 

1 

1 

Local  Dlcty 

1 

1 

1 

Loca 1  Progs 

1 

1 

CONTROL 

Dl CT IONARY/CMS 

PROGRAM  L  IBRARIES 

It  Is  academically  Interesting  to  consider  the  following  possible 
structurl ng: 

1.  Programs  and  Procedur  (at  least  In  the  Ada  world)  have 

"generic"  and  "specific  Instances"  that  are  related 
"hierarchical ly. " 

2.  Data  Names  and  Structures  (In  the  DBMS  database  management 

world)  have  "schema"  and  "data"  that  are  related 
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"h I erarch leal  I  y . " 

3.  Control  and  structures  (In  modern  programming  systems)  have 
pol  Icy,  control,  tasks,  tools,  etc  that  appear  to  be 
related,  In  part,  "h lerarch leal  I y.  " 

The  relationships  between  these  three  are  Indicated  In  the  next 
figure,  which  does  not  suggest  a  hierarchy  that  bears  any 
resemblance  to  that  of  the  distributed  control /dictionary/ I Ibrary 
above. 


Genera 


Systems  and  Programs 


Data  Structure 

/ 


I  / 

Pol  Icy 


6.  Some  Alternative  Distributed  Solutions 

There  have  been  several  ways  of  keeping  track  of  data  and 
programs  In  a  distributed  system;  seme  are: 

1.  Central  Control  with  a  Central Ized  dlrectory/dlc+lonary 

Just  know  all  locations  of  named  objects  and  either  not 
allow  anyone  other  than  central  a<Jn  I  nl  strati  on  to  make 
changes  or  else  control  and  monitor  update. 

2.  Central  and  distributed  dlrectorles/dlc+lonary 

Some  controls  are  needed  to  decide  whose  or  what  changes  are 
allowed.  A  method  of  passing  Information  up  and  down  the 
system  (from  central  to  local  and  back)  Is  essential. 

3.  Broadcast  Updates  to  distributed  directories/dictionary 

In  this,  the  control  Is  always  at  the  local  port,  but  all 
communication  will  be  via  a  “Now  hear  this  ...”  type  of 
message,  and  It  Is  the  responslbll  Ity  of  each  node  to  react 
and  to  update  correctly  when  Informed.  (The  responsibility 
of  the  central  node  I s  to  be  sure  the  message  of  change  Is 
received,  and  then  It  terminates  all  responslbl I Ity. )  This 
Is  a  form  of  "Delegation  of  Authority." 


7.  Seme  Ccmments  on  the  Pol  Icy  Aspects 

Is  there  any  really  high  level  DoD  policy  that  can  be  discerned 
from  the  Ada  and  Software  Initiatives?  It  sems  that  the  only 
sure  one  Is: 
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We  must  reduce  the  cost  of  software. 


But  If  this  Is  the  case,  we  must  ask: 

What  does  this  entail? 


The  paper  so  far  has  tried  to  raise  questions  that  seem  to  be 
central  to  the  theme  of  software  production.  But  they  primarily 
nucleate  on  one  group  of  factors: 

Who  Is  In  charge?  —  Who  sets  policy?  —  Will  it  be  enforced? 

The  whole  question  of  standards  Is  moot  If  only  a  small  part  of 
the  services  are  going  to  use  (and  enforce  use)  of  them.  It 
seems  unlikely  that  there  Is  enough  political  power  (or  true 
Intent)  to  enforce  the  policies  needed  to  gain  through  the  use  of 
Ada  and  STI.  If  we  cannot  be  sure  that  there  Is  a  pol  Icy  for 
hard  standards  In  computing,  we  are  unlikely  to  reach  more  than  a 
few  percentage  points  of  the  predicted  (possible)  cost 

reductions.  If  we  are  not  going  to  control  the  mixture  of 
production  and  run  time  systems,  we  have  again  failed. 

The  ultimate  abll Ity  of  the  DoD  to  reduce  the  cost  of  software 
devolves  on  Its  seriousness.  To  achieve  reductions,  we  must: 

1,  Have  a  good  rationale  for  policy  on  software  production 
and  run-time  standards.  This  must  be  agreed  at  a 
sufficiently  high  level  that  It  cannot  be  transcended  by 
anyone. 

C 1 1  Is  extremely  uni  Ikely  that  this  Is  possible] 

2.  Implement  the  policy  through  a  mechanism  for  control 
based  on  one  of  the  Ideas  presented  here  (the  specific 
method  Is  Irrelevant,  but  a  good  control 
mechanism  Is  essential ) . 

[Otherwise  we  can  only  make  partial  gains,  and  the  chance 
of  the  current  state  of  anarchy  will  continue] 

The  final  question  is  to  ourselves: 

Are  we  playing  any  valuable  part  to  DoD  If  we  only  answer  the 
easy  questions  and  Ignore  the  "real"  problems  —  l.e. ,  the  ones 
that  will  ultimately  show  whether  the  Ada  and  STI  effort  was 
useful  or  just  another  "computer  science  premise." 
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